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Meta Software launches Design/IDEF,™ the 
first CIM modeling tool for desktop engineering. 

Design/IDEF is the fast, accurate and cost-effective 
way to automate Computer Integrated Manufacturing 
(CIM) planning and modeling. 

Now you can create, read and comment on CIM 
models—quickly and easily. And make any modifications 

instantly. So projects are completed . . 

in less time. At a substantial savings, desian IDE 

Design/IDEF is a smart, 
high-performance graphics tool 
that’s powerful enough to handle 
CIM models containing hundreds 
of hierarchically linked diagrams. 

It supports the CIM systems 

design methodology used by the 

US Air Force, major aerospace 

contractors, and large manufactur- “ So «“ 

ing companies. 

No more re-drawing, re-drawing, re-drawing. 

If you move or resize an object, Design/IDEF auto¬ 
matically recreates all associated arrows, text and subor¬ 
dinate objects—without affecting arrow angles or curva¬ 
ture. Since text and graphics are combined, you can 
easily associate text with boxes or arrows. 

As your CIM model evolves, you can move detail to 
a subpage. Design/IDEF will automatically maintain the 
relationships and display the hierarchy. So you save time 
and improve accuracy. 

What’s more, an interactive data dictionary provides 
centralized storage, organization, and reporting. And a 
data capture facility makes it easy to accurately monitor 
and update files. 

Special Introductory Offer. 

Design/IDEF is priced at $2500, but you can pur¬ 
chase it for $2000 until March 31,1988. So act now and 
discover why so many top manufacturing and engineer¬ 
ing companies use Meta Software’s Design/IDEF to speed 
up projects and keep costs under control. 

Write or call toll-free 1 - 800 - 227-4106 for more 
information about Design/IDEF. Inside Massachusetts, 
call 617-576-6920. And fly through CIM modeling in 
record time. 

Available for the Macintosh™ Plus, SE, II. Macintosh is a trademark of Apple 
Computer, Inc. Design/IDEF is a trademark of META Software Corporation. 


Meta Software 

■Pol Meta Software Corporation, 

TI 150 CambridgePark Drive, 

0«-0\ Cambridge, Massachusetts02140. 
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Breakthrough in presentation of simulation results 
SIMSCRIPT II.5 with SIMANIMATION 
Now you see an animated picture of the system 



Transportation network 


Telecommunications-COMNET II.5 


Free trial and training 

See for yourself how simulation 
results are now easier to understand. 

The free trial contains everything 
you need to try SIMANIMATION® 
on your computer. 

We send you SIMSCRIPT II.5, 
animated models, and complete 
documentation. You can build your 
own model or modify one of ours. 

Try the SIMSCRIPT II.5 
language, the timeliness of our sup¬ 
port, the accuracy of our documen¬ 
tation, and the facilities for error 
checking— everything you need for a 
successful project. 

No cost, no obligation. 

Act now for free training 

For a limited time we will also in¬ 
clude free training. 

For immediate information 

Call Hal Duncan at (619) 
457-9681. In the UK call Steve 
Wombell on (01) 940-3606. 



Military operation Presentation graphics 



Mining operation in process Pilot ejection 


Rush information on SIMSCRIPT II.5 
with SIMANIMATION 

Free trial- learn the reasons for the broad 
and growing popularity of SIMSCRIPT II.5 
with SIMANIMATION. 

No cost, no obligation. 

Limited offer-return the coupon today 
and we will also include one free course 
enrollment worth $950. 
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Synchronization, Coherence, and Event Ordering in Multiprocessors 

Michel Dubois, Christoph Scheurich, and Faye A. Briggs 

Efficient multiprocessing depends on a harmonious blend of synchronization, coherence, and event ordering in a system 
that provides the user with a simple logical model of concurrency behavior. 
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tion and operating system fault recovery. 

An Optimum Parallel Architecture for 
High-Speed Real-Time Digital Signal Processing 

Gordon R. Lang, Moez Dharssi, Fred M. Longstaff, Philips. Longstaff, Peter A.S. Metford, and 
Malcolm T. Rimmer 

This parallel processing architecture for real-time digital signal processing has demonstrated virtually 100-percent 
data processing efficiency in a number of areas. 

59 The Source of Authority for Commercial Access Control 

Jonathan D. Moffett and Morris S. Sloman 

Access control systems for a company’s computers should mirror the organization’s internal control systems, based 
on the delegation of authority. 










DEPARTMENTS 


6 President’s Message 

Don’t be a quitnik 

72 Standards 

Dictionary of computer terms 

79 Computer Society News 

Board nominees sought; IEEE Fellows 

84 Update 

88 New Product Reviews 

Screen interface systems 

91 New Products 



Cover photo: The Image Bank 
Photographer: Frank Whitney 
Cover design: Jay Simpson, 
Design & Direction 


In the next issue 

Neural Networks 


98 IC Announcements 


99 Microsystem Announcements 
10 Conferences 
105 Call for Papers 
10 Calendar 
lit) Book Reviews 
119 New Literature 


Computer Society Information Page, 
inside back cover; Change-of-Address 
Form, 102; Membership Application 
Form, 100; Career Opportunities, 109; 
Advertising and Product Indexes, 120; 
Reader Service Card, 120A 















looking at our new System 93 PLUS,™ the fastest solid state mass storage subsystem on the market. 

And it’s ready for delivery, now. 

But don’t blink or you'll miss the Zitel 145 Megabyte/sec block transfer rate for custom bus per¬ 
formance at a sustained 55 nsec cycle time for 64 bit words. And there’s no need to refresh. 

With up to 512 Megabyte capacity per chassis based on 1 Megabit DRAMS and 
modes, our new 93 PLUS is ideal for applications 
like flight simulation, radar processing, uplinks/downlinks, or any high-speed 
data capture and buffering requirement. 

There’s also an off-the-shelf VME interface with a 
sustained 40 Megabyte/sec transfer rate. 

And it does it all without hitting any speed bumps. 

It’s completely solid state and backed by a fully 
operational temperature test that’s part of our 

continuing stringent Quality Assurance Program Tr4wt mmk?d ^ 
, to ensure trouble-free system integration. meets mu spec sio-c. 
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And you’ll easily avoid the biggest speed bumps of all, development time.Talk to us about our 
Turnkey Interface Program and we’11 shift into high gear, helping you move product to market 
in no time. 

So when you’re ready to find out more about the fastest mass storage subsystem, our superior 
Quality Assurance Program and how a Zitel partnership works with you, simply call our toll- 
free number. Wll respond with a copy of “Designing for Performance with System 93!’ 

Our engineers would like to show you how to avoid the speed bumps imposed by 
slower, more cumbersome solutions. 

Toll-free: 1-800-622-5020 

In California (collect): (408) 946-9600 FAX: (408) 262-6754 
TWX: 910-338-0567 TLX: 171607 ZITEL SNJ 
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President’s MESSAGE 



Edward A. Parrish, Jr. 


In the months ahead, I plan to use 
this column as a vehicle for communica¬ 
tion with the membership regarding 
plans and activities of the Computer 
Society. This month, Merlin Smith, vice 
president for membership and informa¬ 
tion, addresses the issue of individual 
professional activities. 

Edward A. Parrish, Jr. 


Don’t be a quitnik 

This year over 33,000 people will drop 
their IEEE memberships—much like 
dropping a magazine subscription. 
About 18,000 will drop their Computer 
Society membership. For some, it’s 
“Your stuff is great. I just don’t have 
time to read or participate.” For 
others, “I just get too many maga¬ 
zines” or “I can read your publications 
in the company library.” For many of 
these people, this will not only be the 
last month of IEEE service, but their 
last support of the profession. If you 
haven’t renewed, we urge you to do so. 

It’s part of being a professional. 

Membership in the IEEE and the Com¬ 
puter Society is more than subscribing 
to a magazine. Being a member sup¬ 
ports the profession even if you don’t 
take the time to read, or can read IEEE 
publications in the library. The profes¬ 
sion needs your support. It’s not just 
numbers, it’s vitality—more resources 
to serve members and the profession. 

The IEEE and the Computer Society 
are volunteer driven, and exist only for 
the benefit of their members and the 
profession. They are nonprofit, and the 
volunteers receive no financial compen¬ 
sation. Your dollars are returned to you 
in the many services offered. We are 
unique in support of the total profes¬ 


sion, from the student level through the 
career of the professional in industry, 
government, or academia. We are 
unique in our services, with programs 
covering timely technology advances, 
applications, research, standards 
development, continuing education, 
professional issues, and recognition of 
achievements. 

Greater participation can mean 
expanded horizons. Our programs can 
help you keep a step ahead. Members 
look to these programs to 

• Adapt to a rapidly changing envi¬ 
ronment 

• Add “how-to” skills to a formal 
education 

• Recognize technology advances 
early 

• Understand new-technology appli¬ 
cations 

• Identify synergisms across technol¬ 
ogy and disciplinal boundaries 

• Gain perspectives and measures for 
judging one’s work 

• Present and test ideas in the soci¬ 
ety’s many forums 

• Anticipate or participate in stan¬ 
dards development 

• Develop education guidelines and 
programs for today’s industry 

• Establish contacts in the profession 

• Build professional recognition and 
prestige 
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Be a pronik. Become an advocate for 
the profession. You’re needed. 
Encourage your associates to join. 
Show them this magazine. They can 
join with the application form herein, 
or request more information on the 
Computer Society by circling number 
202 on the reader service card. 


faculty to be chapter advisors. We’re 
eager to work with you on this, and 
advisors also receive credits for books 
from our Computer Society Press. 
Write us for information: Merlin 
Smith, Membership, IEEE Computer 
Society, 10662 Los Vaqueros Circle, 
Los Alamitos, CA 90720-2578. 


Our greatest need. If you’re in acade¬ 
mia, let the students know they should 
join and be a part of the profession. 
(Students should ask for the student 
application form since they can join at 
substantially reduced rates.) Help us 
form student chapters and identify 


Help us repay our debt to the 
profession —and join us in more of our 
programs. You’ll enjoy it. 

Merlin G. Smith 

VP Membership and Information 



Renewal is easy 

Renewing is a snap. If you haven’t 
already done so, here’s how to do it. 
You have several options: 

• Find your second renewal notice, 
which is probably still on your desk. 

It would have arrived at your address 
a week or so ago. Fill it out, pay the 
fee, send it in! 

• Look for your third renewal 
notice. It will arrive at US and Cana¬ 
dian locations around the end of 
February. (European members will 
receive this in April.) Fill it out, pay 
the fee, send it in! 

• Sometimes these things get lost. 
If this happens to you, just call or 


write the IEEE Service Center in New 
Jersey, 

445 Hoes Lane 
Piscataway, NJ 08854-4150 
(201) 981-0060 

and ask for member services. They’ll 
happily send you a copy of your 
renewal information. Fill it out, pay 
the fee, send it in! 


It’s easy. Not quite as easy as 
doing nothing and dropping out. But 
then, nothing worthwhile ever is, is 
it? 

We look forward to your continued 
participation. Thank you! 
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Call for Papers 

ACM SIGSOFT ’88: Third Symposium on 
Software Development Environments 


Sponsored by: 

ACM-SIGSOFT Boston, Massachusetts 

ACM-SIGPLAN December 5-7, 1988 

In cooperation with: ACM-SIGADA 


General Chairman 


Symposium Scope and Theme: Integrated SDE’s 


Peter B. Henderson (USA) 
Program Chairman 
Barry Boehm (USA) 
Program Committee 
Robert Balzer (USA) 
David R. Barstow (USA) 
Stowe Boyd (USA) 

Lori A. Clarke (USA) 
Mark Dowson (UK) 

Susan L. Graham (USA) 
Masatoshi Matsuo (Japan) 
Bertrand Meyer (France) 
David Notkin (USA) 

Leon Osterweil (USA) 
Maria Penedo (USA) 
Erhard Ploedereder (USA) 
Arthur Pyster (USA) 
Steven Reiss (USA) 

Donald J. Reifer (USA) 
Paul Rook (USA) 

Winston Royce (USA) 
William Scherlis (USA) 
Richard N. Taylor (USA) 
Ian Thomas (France) 

Tony Wasserman (USA) 


The overall scope of the symposium is indicated by the list of topics below, each of which is 
a relevant topic for contributed papers: 


• Monolingual/Multilingual Environments 

• Production Quality Environments 

• Database support for Environments 

• Knowledge-based Environments 

• Workstation Based Environments 

• Applications of AI 

• Human Factors Studies 

• Standardization of Environments 


• Support for the Software Lifecycle 

• Empirical Evaluation using Environments 

• Environment Integration Strategies 

• Distributed/Network Environments 

• Role of Graphics 

• User Interfaces 

• Security concerns in Environments 

• Comparative Analysis of Environments 


The particular theme of the Third Symposium addresses Integrated SDE’s. The primary 
feature distinguishing an SDE from an ad-hoc collections of tools is a set of integration 
mechanisms which enable tools to cooperate efficiently, and which provide users with con¬ 
sistent views of the environment and its services. There are several dimensions of SDE 
integration, such as via languages, object management, process models, methodology, levels 
of abstraction, and user interface management. Authors are encouraged to emphasize their 
treatment of integration issues in their contributed papers. 


Authors should explain what is new and significant about the work presented and must ade¬ 
quately address the following issues: 

a) With regard to the contribution of the paper, how does it relate to similar work? 
Authors must list several key ways in which this contribution is unique or important. 


b) If the paper describes an operational system, why is this different than other similar sys¬ 
tems? What are its advantages and deficiencies? 


Information and Instructions for authors 


Please send five copies of your paper (6000 words max¬ 
imum) to the Program Chairman: 

Barry Boehm, Chair SDE 
TRW-DSG 

One Space Park, R2-2086 
Redondo Beach, CA 90278 USA 
Submission Deadline: April 15, 1988 
Acceptance Notification: July 1, 1988 
Camera-ready paper due: September 1, 1988 

Authors of accepted papers will be requested to sign an 
ACM copyright release form. The best papers will be candi¬ 
dates for planned special issues of appropriate refereed 


journals. Proceedings will be distributed at the Sympo¬ 
sium, as a special joint issue of Software Engineering 
Notes and SIGPLAN Notices, or may be purchased from 
ACM. 

Demonstrations 

Proposals for demonstrations of prototype or produc¬ 
tion quality environments and tools will be accepted by 
the program committee. Six copies of a short abstract (3 
to 5 pages) describing the environment or tool, what is 
new and significant about the system, experience with the 
system, current status and availability of the system, and 
its hardware/software requirements should be submitted by 
April 15, 1988 to the program chairman. 












SURVEY & TUTORIAL SERIES 


Synchronization, Coherence, 
and Event Ordering in 
Multiprocessors 

Michel Dubois and Christoph Scheurich 
Computer Research Institute, University of Southern California 


Faye A. Briggs 
Sun Microsystems 


M ultiprocessors, especially 
those constructed of rela¬ 
tively low-cost microproces¬ 
sors, offer a cost-effective solution to the 
continually increasing need for computing 
power and speed. These systems can be 
designed either to maximize the through¬ 
put of many jobs or to speed up the exe¬ 
cution of a single job; they are respectively 
called throughput-oriented and speedup- 
oriented multiprocessors. In the first type 
of system, jobs are distinct from each 
other and execute as if they were running 
on different uniprocessors. In the second 
type an application is partitioned into a set 
of cooperating processes, and these 
processes interact while executing concur¬ 
rently on different processors. The parti¬ 
tioning of a job into cooperating processes 
is called multitasking 1 * or multithread¬ 
ing. In both systems global resources must 
be managed correctly and efficiently by the 
operating system. The problems addressed 
in this article apply to both throughput- 


•Multitasking is not restricted to multiprocessor sys¬ 
tems; in this article, however, we confine our discus¬ 
sion, with no loss of generality, to multitasking 
multiprocessors. 


| Efficient 
I multiprocessing 
P* depends on a | 
jharr^odicpn^Wegd ofl 
| synchronization, 
rtierencey^nc^B 
ling in a 
thaf provides the user 
with a simple logical 

behavior. 


and speedup-oriented multiprocessor sys¬ 
tems, either at the user level or the 
operating-system level. 

Multitasked multiprocessors are capa¬ 
ble of efficiently executing the many 


cooperating numerical or nonnumerical 
tasks that comprise a large application. In 
general, the speedup provided by multi¬ 
tasking reduces the turnaround time of 
a job and therefore ultimately improves 
the user’s productivity. For applications 
such as real-time processing, CAD/CAM, 
and simulations, multitasking is crucial 
because the multiprocessor structure 
improves the execution speed of a given 
algorithm within a time constraint that is 
ordinarily impossible to meet on a single 
processor employing available technology. 

Designing and programming multipro¬ 
cessor systems correctly and efficiently 
pose complex problems. Synchronizing 
processes, maintaining data coherence, 
and ordering events in a multiprocessor are 
issues that must be addressed from the 
hardware design level up to the program¬ 
ming language level. The goal of this arti¬ 
cle is not only to review these problems in 
some depth but also to show that in the 
design of multiprocessors these problems 
are intricately related. The definitions and 
concepts presented here provide a solid 
foundation on which to reason about the 
logical properties of a specific multiproces- 
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Figure 1. A shared-memory multiprocessor with optional private caches. The inter¬ 
connection network may be either a simple bus or a complex network. 


sor and to demonstrate that the hardware 
adheres to the logical model expected by 
the programmer. This foundation aids in 
understanding complex but useful 
architectures such as multiprocessors with 
private caches or with recombining inter¬ 
connection networks (Figure l). 2 Other 
important issues, such as scheduling and 
partitioning, have been addressed in a 
previous survey article. 3 Readers who are 
not familiar with the concept of cache 
memory should consult the survey by 
Smith. 4 


Basic definitions 

The instruction set of a multiprocessor 
usually contains basic instructions that are 
used to implement synchronization and 
communication between cooperating 
processes. These instructions are usually 
supported by special-purpose hardware. 
Some primary hardware functions are 
necessary to guarantee correct interprocess 
communication and synchronization, 
while other, secondary hardware functions 
simplify the design of parallel applications 
and operating systems. The notions of syn¬ 
chronization and communication are dif¬ 
ficult to separate because communication 


primitives can be used to implement syn¬ 
chronization protocols, and vice versa. In 
general, communication refers to the 
exchange of data between different 
processes. Usually, one or several sender 
processes transmit data to one or several 
receiver processes. Interprocess communi¬ 
cation is mostly the result of explicit direc¬ 
tives in the program. For example, 
parameters passed to a coroutine and 
results returned by such a coroutine con¬ 
stitute interprocess communications. Syn¬ 
chronization is a special form of 
communication, in which the data are con¬ 
trol information. Synchronization serves 
the dual purpose of enforcing the correct 
sequencing of processes and ensuring the 
mutually exclusive access to certain shared 
writable data. For example, synchroniza¬ 
tion primitives can be used to 

(1) Control a producer process and a 
consumer process such that the consumer 
process never reads stale data and the pro¬ 
ducer process never overwrites data that 
have not yet been read by the consumer 
process. 

(2) Protect the data in a database such 
that concurrent write accesses to the same 
record in the database are not allowed. 
(Such accesses can lead to the loss of one 
or more updates if two processes first read 
the data in sequence and then write the 


updated data back to memory in 
sequence.) 

In shared-memory multiprocessor sys¬ 
tems, communication and synchroniza¬ 
tion are usually implemented through the 
controlled sharing of data in memory. 

A second issue addressed in this article 
is memory co herence , a system’s ability to 
execute memory operations correctly. 
Censier and Feautrier define a coherent 
memory scheme as follows: “A memory 
scheme is coherent if the value returned on 
a Load instruction is always the value 
given by the latest Store instruction with 
the same address.” 5 This definition has 
been useful in the design of cache coher¬ 
ence mechanisms. 4 As it stands, however, 
the definition is difficult to interpret in the 
context of a multiprocessor, in which data 
accesses may be buffered and may not be 
atomic. Accesses are buffered if multiple 
accesses can be queued before reaching 
their destination, such as main memory or 
caches. An access by processor / on a var¬ 
iable X is atomic if no other processor is 
allowed to access any copy of X while the 
access by processor i is in progress. It has 
been shown that memoijaficessesjieed not 
be atomic at the fif rtEwuieievel for correct 
execution of concurrent pro grams. 6,7 
Correctness of execution depends on the 
expected behavior of the machine. Two 
major classes of logical machine behavior 
have been identified because they are com¬ 
mon in existing multiprocessor systems: 
the strongly ordered and the weakly 
ordered models of behavior. 7 The hard¬ 
ware of the machine must enforce these 
models by proper ordering of storage 
accesses and execution of synchronization 
and communication primitives. This leads 
to the third issue, the ordering of events. 

The strictest logical model for the order¬ 
ing of events is called sequential con¬ 
sistency, defined by Lamport. In a 
multiprocessor sequential consistency 
refers to the allowable sequence of execu¬ 
tion of instructions within the same pro¬ 
cess and among different concurrent 
processes. Lamport defines the term more 
rigorously: “ [A system is sequentially con¬ 
sistent if] the result of any execution is the 
same as if the operations of all the proces¬ 
sors were executed in some sequential 
order, and the operations of each individ¬ 
ual processor appear in this sequence in the 
order specified by its program.” 8 

Since the only way that two concurrent 
processors can affect each other’s execu¬ 
tion is through the sharing of writable data 
and the sending of interrupt signals, it is 


COMPUTER 





















the order of these events that really mat¬ 
ters. In systems that are sequentially con¬ 
sistent we say that events are strongly 
ordered. 

However, if we look at many systems 
(transaction systems, for example), it 
becomes clear that sequential consistency 
is often violated in favor of a weaker con¬ 
dition. In many machines it is often 
implicitly assumed that the programmer 
should make no assumption about the 
order in which the events that a process 
generates are observed by other processes 
between two explicit synchronization 
points. Accesses to shared writable data 
should be executed in a mutually exclusive 
manner, controlled by synchronizing var¬ 
iables. Accesses to synchronizing variables 
can be detected by the machine hardware 
at execution time. Strong ordering of 
accesses to these synchronizing variables 
and restoration of coherence at synchro¬ 
nization points are therefore the only re¬ 
strictions that must be upheld. In such 
systems we say that events are weakly 
ordered. Weak ordering may result in 
more efficient systems, but the implemen¬ 
tation problems remain the same as for 
strong ordering: strong ordering must still 
be enforced for synchronizing variables 
(rather than for alTshared writable data). 

We can infer from this discussion that 
synchronization, coherence, and ordering 
of events are closely related issues in the 
design of multiprocessors. 


Communication and 
synchronization 

Communication and synchronization 
are two facets of the same basic problem: 
how to design concurrent software that is 
correct and reliable, especially when the 
processes interact by exchanging control 
and data information. Multiprocessor sys¬ 
tems usually include various mechanisms 
to deal with the various granules of syn- 
chronizable resources. Usually, low-level 
and simple primitives are implemented 
directly by the hardware. These primitives 
are the basic mechanisms that enforce 
mutual exclusion for more complex 
mechanisms implemented in microcode or 
software. 

Hardware- l evel synchron ization mech- 
a nisms. A ll multiprocessors include hard¬ 

ware mechanisms to enforce atomic op¬ 
erations. The most primitive memory 
operations in a machine are Loads and 


{Processor 1:} 
A: = 0 


A: = 1 /* event S1(A) */ 

LABI: If (B=1) goto LABI /* event L1(B) */ 
<critical section > 

A: = 0 

{Processor 2:} 

B: = 0 


B:=1 /* event S2(B) */ 

LAB2: If (A =1) goto LAB2 /* event L2(A) */ 
ccritical section > 

B:=0 


Figure 2. Synchronization protocol using two shared variables, A and B. 


Stores. With atomic Loads and Stores 
complex synchronization protocols can be 
^Emill. figure 1 depicts a simple protocol. 

"Before a processor can enter its critical sec¬ 
tion, it sets its control variable (A for 
processor 1 and B for processor 2) to 1. 
Hence, for both processors to be in their 
critical sections concurrently, both A and 
B must equal 1. But this is not possible, 
since a processor cannot enter its critical 
section if the other processor’s control var¬ 
iable equals 1. Therefore, the two proces¬ 
sors cannot execute their respective critical 
sections concurrently. This simple pro¬ 
tocol can be deadlocked, but the problem 
can be remedied. 8 Such protocols are 
hard to design, understand, and prove cor¬ 
rect, and in many cases they are inefficient. 

More sophisticated synchronization 
primitives are usually implemented in 
hardware. If the primitive is simple 
enough, the controll er of the memory' 
bank can execute the primitive at the mem ¬ 

ory in the same way it executes a Load or 
a Store, at the added cost of a more com¬ 
plex memory controller. This is typically 
the case for the Test&Set and the 
Full/Empty bit primitives described 
below. Interprocessor interrupts are also 
possible hardware mechanisms for syn¬ 
chronization and communication. To send 
a message to another process currently 


running on a different processor, a process 
can send an interrupt to that processor to 
notify the destination process. 

A common set of synchronization 
primitives consists of Test&Set(lock) and 
Reset(lock). The semantics of Test&Set 
and Reset are 
TEST&SET(lock) 

{ temp *- lock; lock *- 1; 
return temp-, } 

RESET(lock) 

{ lock 0; } 

The microcode or software wil l usually 
repeat the Test&Set until the returned 
value is 0. Synchronization at this level 
implies some form o f busy waiting, which 
ties up a processor in an idle loop and 
increases the memory bus traffic and con¬ 
tention. Thetypeof loc k that relies o n 
busy waiting is called a smn-lock . 

To avoid spinning, interprocessor inter¬ 

rupts are used. A lock that relies on inter¬ 
rupts instead of spinnin g is called a 
smnend-lock (also called sleep-lock in the 
C.mmp 1 ). This lock is similar to the spin- 
lock in the sense that a process does not 
relinquish the processor while it is waiting 
on a suspend-lock. However, whenever it 
fails to obtain the lock, it records its sta¬ 
tus in one field of the lock and disables all 
interrupts except interprocessor inter- 
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rupts. When a process frees the lock, it sig- 
^ £als~aiT^aitlhr , pr5t^sDrsThro TIgti~«i 
^interprocessor interrupt. This mechanism 
prevents' the excessive interconnection 
traffic caused by busy waiting but still 
consumes processor cycles. Spin-locks 
and suspend-locks can be based onprimi- 
tives similar to Test&Set, such as 
Compare&Swap. 

The Compare&Swap(r 1 ,r2, w) primitive 
is a synchronization primitive in the IBM 
370 architecture; rl and r2 are two 
machine registers, and w points to a mem¬ 
ory location. The success of the 
Compare&Swap is indicated by the flag z. 
The semantics of the Compare&Swap 
instruction are 

COMPARE&SWAPfrl ,r2, w) 

{ temp *- w; if (temp = rl) 
then {w •*- r2; z 1;} 
else {rl •*- temp ; z 0;} 

} 

Test&Set and Compare&Swap are also 
called read-modify-write (RMW) primi¬ 
tives. A common performance problem 
associated with these basic synchroniza¬ 
tion primitives is the complexity of lock¬ 
ing protocols. If A processes attempt to 
access a critical section at the same time, 
the memory system must execute A basic 
lock operations, one after the other, even 
if at most one process is successful. The 
NYU Ultracomputer 2 and the RP3 
multiprocessor 9 use the Fetch&Add(x,a) 
primitive, where x is a shared-memory 
word and a is an increment. When a sin¬ 
gle processor executes the Fetch&Add on 
x, the semantics are 

FETCH&ADD(x, a) 

{ temp *- x; x *- temp + a; 
return temp; } 

The implementation of the Fetch&Add 
primitive on the Ultracomputer is such 
that the complexity of an A-way synchro¬ 
nization on the same memory word is 
independent of A. The execution of this 
primitive is distributed in the interconnec¬ 
tion network between the processors and 
the memory module. If A processes 
attempt to Fetch&Add the same memory 
word simultaneously, the memory is 
updated only once, by adding the sum of 
the A increments, and a unique value is 
returned to each of the A processes. The 
returned values correspond to an arbitrary 
serialization of the A requests. From the 
processor and memory point of view, the 
result is similar to a sequential execution 
of AFetch&Adds, bj ^it is performed in 
one operation. Consequently, the 


Fetch&Add primitive is extremely effec¬ 
tive in accessing sequentially allocated 
queue structures and in the forking of 
processes with identical code that operate 
on different data segments. For example, 
the following high-level parallel Fortran 
statement 10 can be executed in parallel by 
P processors if there is no dependency 
between iterations of the loop: 

DOALL A= 1 to 100 
< code using A> 

ENDDO 

Each processor executes a Fetch&Add 
on Abefore working on a specific iteration 
of the loop. Each processor will return a 
unique value of A, which can be used in the 
code segment. The code for each proces¬ 
sor is as follows (Ais initially loaded with 
the value 1): 

n - FETCH&ADD (A,l) 

while (n < 100) do 
{ < code using A> 
n - FETCH&ADD (A,l); 

} 

In the HEP (Heterogeneous Element 
Processor) system, shared-memory words 
are tagged as empty or full. Loads of such 
words succeed only after the word is 
updated and tagged as full. After a suc¬ 
cessful Load, the tag can be reset to empty. 
Similarly, the Store on a full memory word 
can be prevented until the word has been 
read and the tag cleared. These mechan¬ 
isms can be used to synchronize processes, 
since a process can be made to wait on an 
empty memory word until some other 
process fills it. This system also relies on 
busy waiting, and memory cycles are 
wasted on each trial. Each processor in the 
HEP is a multistream pipeline, and several 
process contexts are present in each 
processor at any time. A different process 
can immediately be activated when an 
attempt to synchronize fails. Very few 
processor cycles are wasted on synchroni¬ 
zation. However, the burden of managing 
the tags is left to the programmer or the 
compiler. A more complex tagging scheme 
is advocated for the Cedar machine. 3 

anismsT Two~approaches to syrichrbniza- 
tion are popular in multiprocessor 
operating systems: semaphores and mes¬ 
sage passing. We wiWisStTssmessage pass¬ 
ing in dTC'next section. Operations on 
semaphores are P and V. A binary sema¬ 
phore has the values 0 or 1, which signal 
acquisition and blocking, respectively. A 
counting semaphore can take any integer 


value greater than or equal to 0. The 
semantics of the P and V operations are 
P(s) 

{ if (s > 0) then 
1 ); 
else 

{ Block the process and append it 
to the waiting list for s; 

Resume the highest priority pro¬ 
cess in the READY LIST;} 

} 

V(s) 

{ if (waiting list for 5 empty) then 

•s-(J + i); 

else 

{ Remove the highest priority pro¬ 
cess blocked for 5; 

Append it to the READY LIST;} 

} 

In these two algorithms shared lists are 
consulted and modified (namely, the 
Ready List* and the waiting list for s). 
These accesses as well as the test and mod¬ 
ification of s have to be protected by spin- 
locks, suspend-locks, or Fetch&Adds 
associated with semaphore s and with the 
lists. In practice, P and V are processor 
instructions or microcoded routines, or 
they are operating system calls to the pro¬ 
cess manager. The process manager is the 
part of the system kernel controlling pro¬ 
cess creation, activation, and deletion, as 
well as management of the locks. Because 
the process manager cap be called from 
different processors at the same time, its 
associated data structures must be pro¬ 
tected. Semaphores are particularly well 
adapted for synchronization. Unlike spin- 
locks and suspend-locks, semaphores are 
not wasteful of processor cycles while a 
process is waiting, but their invocations 
require more overhead. Note that locks are 
still necessary to implement semaphores. 

Another synchronization primitive 
implemented in software or microcode is 
Barrier, used to “join” a number of par¬ 
allel processes. All processes synchroniz¬ 
ing at a barrier must reach the barrier 
before any one of them can continue. Bar¬ 
riers can be defined as follows after the 
task counter Count has been initialized to 
zero: 

BARRIER(A) 

{ count: = count + 1; 

if (count > A) then 

{ Resume all processes on barrier 
queue; 


"The Ready List is a data structure containing the 
descriptors of processes that are runable. 
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Table 1. Synchronization, communication, and coherence in various multiprocessors. 


Multiprocessor 

Number of 

processors 

CPU architecture 

Hardware 

primitives 

Cache 

Coherence 

scheme 

IBM 3081 

<4 

IBM 370 

Compare&Swap 
(CS, CDS), 

Test&Set (TS) 

Write-back 

Central table 

Synapse N+ 1* 

<32 

Motorola 68000 

Compare&Swap 

(CAS), 

Test&Set (TAS) 

Write-back 

Distributed table/ 
bus watching 

Denelcor HEP* 

100s 

Custom 

Full/empty bit 

No cache 


IBM RP3f 

100s 

IBM ROMP 

Fetch&Op 
(e.g., Fetch&Add) 

Write-back 

No shared 
writable 
data in cache 

NYU Ultracomputer f 

100s 


Fetch&Add 

Write-back 

No shared 
writable 
data in cache 

Encore Multimax 

<20 

National Semiconductor 
32032 

Test&Set 

(“interlocked” 

instructions) 

Write-through 
(two processors 
share each cache) 

Bus watching 

Sequent Balance 8000 

<12 

National Semiconductor 
32032 

Test&Set 

(spin-lock using lock 
cache and bus 
watching) 

Write-through 

Bus watching 


•Commercial machines no longer in production. 
tExperimental prototype. 


Reset count; } 
else 

Block task and place in barrier 
queue; 

} 

The first N -1 tasks to execute Barrier 
would be blocked. Upon execution of Bar¬ 
rier by the Mh task, all N tasks are ready 
to resume. In the HEP each task that is 
blocked spin-locks on a Full/Empty bit. 
The Mh task that crosses the barrier writes 
into the tagged memory location and 
thereby wakes up all the blocked tasks. 
This technique is very efficient for execut¬ 
ing parallel, iterative algorithms common 
in numerical applications. 

Interprocess communication. In a 

shared-memory multiprocessor, inter¬ 
process communication can be as simple 
as one processor writing to a particular 
memory location and another processor 
reading that memory location. However, 
since these activities occur asyn¬ 
chronously, communication is in most 
cases implemented by synchronization 
me'chanisms. The reading process must be 
informed at what time the message to be 


read is valid, and the writing process must 
know at what time it is allowed to write to 
a particular memory location without de¬ 
stroying a message yet to be read by 
another process. Therefore, communica¬ 
tion is often implemented by mutually 
exclusive accesses to mailboxes. Mailboxes 
are configured and maintained in shared 
memory by software or microcode. 

Message-based communication can be 
synchronous or asynchronous. In a syn¬ 
chronous system the sender transmits a 
message to a receiving process and waits 
until the receiving process responds with 
an acknowledgment that the message has 
been received. Symmetrically, the receiver 
waits for a message and then sends an 
acknowledgment. The sender resumes exe¬ 
cution only when it is confirmed that the 
message has been received. In asyn¬ 
chronous systems the sending process does 
not wait for the receiving process to receive 
the message. If the receiver is not ready to 
receive the message at its time of arrival, 
the message may be buffered or simply 
lost. Buffering can be provided in hard¬ 
ware or, more appropriately, in mailboxes 
in shared memory. 


A summary of synchronization and 
communication primitives for different 
processors is given in Table 1. 


Coherence in 
multiprocessors 

Coherence problems exist at various 
levels of multiprocessors. Inconsistencies 
(i.e., contradictory information) can occur 
between adjacent levels or within the same, 
level of a memory hierarchy. For example, 
in a cache-based system with write-back 
caches, cache and main memory may con¬ 
tain inconsistent copies of data. 4 Multiple 
caches conceivably could possess different 
copies of the same memory block because 
one of the processors has modified its 
copy. Generally, this condition is not 
allowable. 

In some cases data inconsistencies do 
not affect the correct execution of a pro¬ 
gram (for example, inconsistencies 
between memory and write-back caches 
may be tolerated). In the following para¬ 
graphs we identify the cases for which data 
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Figure 3. Cache configuration after a Load on X by processors 0 and 1. Copies in 
both caches are consistent. 
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Figure 4. Cache configuration after a Store on X by processor 0 (write-through 
cache). The copies are inconsistent. 


inconsistencies pose a problem and discuss 
various solutions. 

Conditions for coherence. Data coher¬ 
ence problems do not exist in multiproces¬ 
sors that maintain only a single copy of 
data. For example, consider a shared- 


memory multiprocessor in which each 
CPU does not have a private memory or 
cache (Figure 1 without optional caches). 
If Loads, Stores, and RMW cycles are 
atomic, then data elements are accessed 
and modified in indivisible operations. 
Each access to an element applies to the 


latest copy. Simultaneous accesses to the 
same element of data are serialized by the 
hardware. 

Cache coherence problems exist in mul¬ 
tiprocessors with private caches (Figure 1 
with optional caches) and are caused by 
three factors: sharing of writable data, 
process migration, and I/O activity. To 
illustrate the effects of these three factors, 
we use a two-processor architecture with 
private caches (Figures 3-5). We assume 
that an element X is referenced by the 
CPUs. Let Lj{X) and Sj{X) denote a Load 
and a Store by processor j for element X 
in memory, respectively. If the caches do 
not contain copies of X initially, a Load of 
X by the two CPUs results in consistent 
copies of X, as shown in Figure 3. Next, if 
one of the processors performs a Store to 
X, then the copies of X in the caches 
become inconsistent. A Load by the other 
processor will not return the latest value. 
Depending on the memory update policy 
used in the cache, the cache level may also 
be inconsistent with respect to main mem¬ 
ory. A write-through policy maintains 
consistency between main memory and 
cache. However, a write-back policy does 
not maintain such consistency at the time 
of the Store; memory is updated eventu¬ 
ally when the modified data in the cache 
are replaced or invalidated. Figures 4 and 
5 depict the states of the caches and mem¬ 
ory for write-through and write-back poli¬ 
cies, respectively. 

Consistency problems also occur 
because of the I/O configuration in a sys¬ 
tem with caches. In Figure 6 the I/O 
processor (IOP) is attached to the bus, as 
is most commonly done. If the current 
state of the system is reached by an L 0 (X) 
and S 0 (A) sequence, a modified copy of X 
in cache 0 and main memory will not have 
been updated in the case of write-back 
caches. A subsequent I/O Load of Xby 
the IOP returns a “stale” value of X as 
contained in memory. To solve the con¬ 
sistency problem in this configuration, the 
I/O processor must participate in the 
cache coherence protocol on the bus. The 
configuration in Figure 7 shows the IOPs 
sharing the caches with the CPUs. In this 
case I/O consistency is maintained if 
cache-to-cache consistency is also main¬ 
tained; an obvious disadvantage of this 
scheme is the likely increase of cache per¬ 
turbations and poor locality of I/O data, 
which will result in high miss ratios. 

Some systems allow processes to 
migrate—i.e., to be scheduled in different 
processors during their lifetime—in order 
to balance the work load among the 


COMPUTER 





























processors. If this feature is used in con 
junction with private caches, data incor 
sistencies can result. For example, process 
A, which runs on CPU 0 , may alter data 
contained in its cache by executing S 0 (A) 
before it is suspended. If process A 
migrates to CPU! before memory has 
been updated with the most recent value of 
X, process A may subsequently Load the 
stale value of X contained in memory. 

It is obvious that a mere write-through 
policy will not maintain consistency in the 
system, since the write does not automat¬ 
ically update the possible copies of the data 
contained in the other caches. In fact, 
write-through is neither necessary nor 
sufficient for coherence. 

Solutions to the cache coherence prob¬ 
lem. Approaches to maintaining coher¬ 
ence in multiprocessors range from simple 
architectural principles that make incoher¬ 
ence impossible to complex memory 
coherence schemes that maintain coher¬ 
ence “on the fly” only when necessary. 
Here we list these approaches from least to 
most complex: 

(1) A simple architectural technique is 
to disallow private caches and have only 
shared caches that are associated with the 
main memory modules. Every data access 
is made to the shared cache. A network 
interconnects the processors to the shared 
cache modules. 


(2) For performance considerations it is 
desirable to attach a private cache to each 
CPU. Data inconsistency can be prevented 
by not caching shared writable data; sucK_ 

data are called noncac hable. Examples of 

shared writable data are locks, shared data 
structures such as process queues, and any 


other data protected by critical sections. 
Instructions and other data can be copied 
into caches as usual. Such items are 
referred to as cachable. The compiler must 
tag data as either c ac hable or noncachable? 

The hardware must adhere to the meaning 

of the tags. This technique, apparently 
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W(/') = Write to block by processor /'. 
R(/) = Read block by processor /. 

Z(/) = Displace block by cache /'. 


W(/‘) = Write to block by processor/(/ * /). 
R(/) = Read block by processor/'(/' * i). 
Z(/') = Displace block by cache j (/ * i). 


Figure 8. State diagram for a given block in cache i for a write-through coherence 
protocol. 



W(/') = Write to block by processor /. W(/') = Write to block by processor j (/ * /). 

R(/) = Read block by processor /. R(/) = Read block by processor /(/ * /'). 

Z(/) = Displace block by cache /'. Z(/') = Displace block by cache / (/ # /). 


Figure 9. State diagram for a given block in cache i for a write-back coherence 
protocol. 


simple in principle, must rely on the detec¬ 
tion within each CPU that a block is each- 
able or not. Such a detection can be made 
in a virtual memory environment by tag¬ 
ging each page. The tag is stored in entries 
in the CPU’s translation buffers. Transla¬ 
tion buffers (TBs) are similar to caches, 
but they store virtual-to-physical address 
translations. 

(3) If all shared writable data are 
declared noncachable, the performance 
may be degraded appreciably. If accesses 
to shared writable data always occur in 
critical sections, then such data can be 


cached. Only the locks that protect the crit¬ 
ical sections must remain noncachable. 
However, to maintain data consistency, all 
data modified in the critical section must 
be invalidated in the cache when the criti¬ 
cal section is exited. This operation is often 
referred to as a cache flush. The flushing 
operation ensures that no stale data remain 
in the cache at the next access to the criti¬ 
cal section. If another cache accesses the 
data via the acquisition of the lock, con¬ 
sistency is maintained. This scheme is ade¬ 
quate for transaction-processing systems 
in which a shared record is acquired, 


updated in a critical section, and subse¬ 
quently released. It works for write- 
through caches; for write-back caches, the 
design is more complex. 

(4) A scheme allowing shared writable 
data to exist in multiple caches employs a 
centralized global table 5 and is used in 
many mainframe multiprocessor systems, 
such as the IBM 308x. The table stores the 
status of memory blocks so that coherence 
enforcement signals, called cache cross- 
interrogates (XI), can be generated on the 
basis of the block status. To maintain con¬ 
sistency, XI signals with the associated 
block address are propagated to the other 
caches either to invalidate or to change the 
state of the copies of the referenced block. 
An arbitrary number of caches can contain 
a copy of a block, provided that all the 
copies are identical. We refer to such a 
copy as a read-only copy (RO). To modify 
a block present in its cache, the processor 
must own the block with read and write 
access. When a block is copied from mem¬ 
ory into cache, the block is tagged as exclu¬ 
sive (EX) if the cache is the only cache that 
has a copy of the block. A block is owned 
exclusively with read and write (RW) 
access when it has been modified. Only 
one processor can own an RW copy of a 
block at any time. The state IN (invalid) 
signals that the block has been invalidated. 

The centralized table is usually located 
in the storage control element, which may 
also incorporate a crossbar switch that 
connects the CPUs to the main memory. 
To limit the accesses to the global table, 
local status flags can be provided in the 
cache directories for the blocks that reside 
in the cache. Depending on the status of 
the local flags and the type of request, the 
processor is allowed to proceed or is 
required to consult the global table. 

(5) In bus-oriented multiprocessors the 
table that records the status of each block 
can be efficiently distributed among 
processors. The distributed-table scheme 
takes advantage of the broadcasting capa¬ 
bility of the bus. Typically, consistency 
between the caches is maintained by a bus¬ 
watching mechanism, often called a 
snoopy cache controller, which imple¬ 
ments a cache coherence protocol on the 
bus. In a simple scheme for write-through 
caches, all the snoopy controllers watch 
the bus for Stores. If a Store is made to a 
location cached in remote caches, then the 
copies of the block in remote caches are 
either invalidated or updated. This scheme 
also maintains coherence with I/O 
activity. Figure 8 depicts a state diagram 
of the block state changes depending on 
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the access type and the previous state of the 
block. A similar scheme was applied in the 
Sequent Balance 8000 multiprocessor, 
which can be configured with up to 12 
processors. 

The efficiency of the hardware that 
maintains coherence on the fly is vital. 
Recognizing that the Store traffic may 
contribute to bus congestion in a write- 
through system, Goodman proposed a 
scheme called write-once, in which the ini¬ 
tial Store to a block copy in the cache also 
updates memory. 11 This Store also invali¬ 
dates matching entries in remote caches, 
thereby ensuring that the writing proces¬ 
sor has the only cached copy. Further¬ 
more, Stores can be performed in the 
cache at the cache speed. Subsequent 
updates of the modified block are made in 
the cache only. A CPU or IOP Load is 
serviced by the unit (a cache or the mem¬ 
ory) that has the latest copy of the block. 

Multiprocessors with write-back caches 
rely on an ownership protocol. When the 
memory owns a block, caches can contain 
only RO copies of the block. Before a 
block is modified, ownership for exclusive 
access must first be obtained by a read- 
private bus transaction, which is broadcast 
to the caches and memory. If a modified 
block copy exists in another cache, mem¬ 
ory must first be updated, the copy invali¬ 
dated, and ownership transferred to the 
requesting cache. Figure 9 diagrams mem¬ 
ory block state transitions brought about 
by processor actions. The first commercial 
multiprocessor with write-back caches was 
the Synapse N + 1. 

Variants of the cache coherence bus pro¬ 
tocols have been proposed. One scheme, 
proposed for the Spur project at the Uni¬ 
versity of California, Berkeley, combines 
compile-time tagging of shared and private 
data and the ownership protocol. In 
another system, the Xerox Dragon multi¬ 
processor, a write is always broadcast to 
other caches and main memory is updated 
only on replacement. These bus protocols 
are described and their performances com¬ 
pared in an article by Archibald and 
Baer. 12 

Advantages and disadvantages. 

Although scheme 1 provides coherence 
while being transparent to the user and the 
operating system, it does not reduce mem¬ 
ory conflicts but only the memory access 
latency. Shared caches, by necessity, con¬ 
tradict the rule that processors and caches 
should be as close together as possible. I/O 
accesses must be serviced via the shared 
caches to maintain coherence. 


Tagging shared 
writable data fails to 
alleviate the coherence 
problem caused by 
I/O accesses. 


There are a number of disadvantages 
associated with scheme 2, which tags data 
as cachable or noncachable. The major 
one is the nontransparency of the multi¬ 
processor architecture to the user or the 
compiler. The user must declare data ele¬ 
ments as shared or nonshared if a concur¬ 
rent language such as Ada, Modula-2, or 
Concurrent Pascal is used. 13 Alterna¬ 
tively, a multiprocessing compiler, such as 
Parafrase, 10 can classify data as shared or 
nonshared automatically. The efficiency 
of these approaches depends respectively 
on the ability of the language to specify 
data structures (or parts thereof) that are 
shared and writable and of the compiler to 
detect the subset of shared writable data. 
Since in practical implementations a whole 
page must be declared as cachable or not, 
internal fragmentation may result, or 
more data than the shared writable data 
may become noncachable. 

Tagging shared writable data also fails 
to alleviate the coherence problem caused 
by I/O accesses. Either caches must be 
flushed before I/O is allowed to proceed, 
or all data subject to I/O must be tagged 
as noncachable as well. Depending on the 
frequency of I/O operations, both 
approaches reduce the overall hit rate of 
the caches and hence the speedup obtained 
by using caches. 

Another common drawback of tagging 
shared writable data rather than maintain¬ 
ing coherence on the fly is the inefficiency 
caused by process migration. Caches must 
be flushed before each migration or pro¬ 
cess migration must be disallowed at the 
cost of limiting scheduling flexibility. 

Scheme 3—flushing caches only when 
synchronization variables are accessed— 
has performance problems. In practice the 
whole cache has to be flushed, or else the 
data accessed in a critical section must be 
tagged in the cache. I/O must also be 
preceded by cache flushing. Note that the 
programmer must be aware that coherence 
is restored only at synchronization points. 


Scheme 3 appears to be attractive only for 
small caches. 

Scheme 4 solves the problems caused by 
I/O accesses and process migration. How¬ 
ever, a global table that must be accessed 
by all cache controllers can become a bot¬ 
tleneck, even when XIs are filtered by 
hardware. But the main problem of this 
coherence scheme is the distance between 
the processors and the global table. As 
processors become faster, the access 
latency of the table becomes a limiting fac¬ 
tor of system performance; in particular, 
when cache access times are very fast, the 
time penalty for a miss (miss penalty) must 
be minimized. 

By distributing the table among the 
caches, the last scheme partly solves the 
problems of table access contention and 
latency. However, the complexity of the 
bus interface unit is increased because it 
has to “watch” the bus. Furthermore, 
since the scheme relies on a broadcast bus, 
the number of processors that can be inter¬ 
connected is limited by the bus bandwidth. 

Ping-pong effect. In systems with 
caches employing scheme 4 or 5, the exe¬ 
cution of synchronization primitives, such 
as atomic read-modify-write memory 
cycles, can create additional access penal¬ 
ties. If two or more processors are spinning 
on a lock, RMW cycles that cause the lock 
variable to bounce repeatedly from one 
cache to another are generated. This can 
be aggravated by clustering different locks 
into a given block of memory. However, 
if RMW operations are implemented care¬ 
fully, spin-locks can be efficient. 

Let us illustrate the ping-pong problem 
by an example and discuss techniques for 
reducing system performance degrada¬ 
tions. In this example we will assume the 
use of the Test&Set(lock) instruction; 
however, the problem can occur with other 
primitives. The traditional segment of 
code executed to acquire access to a criti¬ 
cal section via a spin-lock is the following: 

while (TEST&SET(lock) = 1) do nothing; 

/* spin-lock with RMW cycles */ 

< execute critical section > 
RESET(lock); 

/* exit critical section */ 

Assume that each processor has a private 
write-back cache and that three or more 
processors attempt to access the critical 
section concurrently. If processor P 0 suc¬ 
ceeds in acquiring the lock, the other 
processors (P] and P 2 ) will spin-lock and 
cause the modified lock variable to be 
invalidated in the other processors’ caches 
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for each access to the lock. As a result of 
the invalidation of the modified lock var¬ 
iable, the block is transferred to the 
requesting cache—a significant penalty. 
The modification is a result of the writing 
in the last part of the RMW memory cycle. 

One technique for avoiding the ping- 
pong effect is to use the following segment 
of code in place of the while statement in 
the previous code segment: 
repeat 

while (LOAD(lock) = 1) do nothing; 
/* spin without modification */ 
until (TEST&SET(lock) = 0); 

In this segment of code the lock is first 
loaded to test its status. If available, a 
Test&Set is used to attempt acquisition. 
However, while a processor is attempting 
to acquire the lock, it “spins” locally in its 
cache, repeating the execution of a tight 
loop made of a Load followed by a Test. 
This spinning causes no invalidation traf¬ 
fic on the bus. On a subsequent release of 
the lock, the processors contend for the 
lock, and only one of them will succeed. 
The ping-pong problem is solved; spin- 
locks can therefore be implemented effi¬ 
ciently in cache-based systems. 

Ping-ponging also occurs for shared 
writable variables. A typical example is the 
index N in the Doall loop described 
earlier, in the section on hardware-level 
synchronization mechanisms. Unless the 
implementation of Fetch&Add is carefully 
designed, accesses to the index A create a 
“hot spot,” * 1 2 3 * * * * * 9 which in a cache-based sys¬ 
tem results in intense ping-ponging 
between the caches. The careful imple¬ 
mentation of synchronization primitives 
and the creation of hot spots in cache- 
based systems are research topics that 
deserve more attention. 


Strong and weak 
ordering of events 

The mapping of an algorithm as con¬ 
ceived and understood by a human pro¬ 
grammer into a list of machine instructions 
that correctly implement that algorithm is 
a complex process. Once the translation 
has been accomplished, however, it is rela¬ 
tively easy in the case of a uniprocessor to 
understand what modifications of the 
machine code can be made without alter¬ 
ing the outcome of the execution. A com¬ 
piler, for example, can resequence 
instructions to boost performance, or the 
processor itself can execute instructions 


Local dependency 
checking is necessary, 
but it may not 
preserve the intended 
outcome of a 
concurrent execution. 


out of order if it is pipelined. This is allow¬ 
able in uniprocessors, provided that hard¬ 
ware mechanisms (interlocks) exist to 
check data and control dependencies 
between instructions to be executed con¬ 
currently or out of program order. 

If a processor is a part of a multiproces¬ 
sor that executes a concurrent program, 
then such local dependency checking is still 
necessary but may not be sufficient to pre¬ 
serve the intended outcome of a concur¬ 
rent execution. Maintaining correctness 
and predictability of the execution of con¬ 
current programs is more complex for 
three reasons: 

(1) The order in which instructions 
belonging to different instruction streams 
are executed is not fixed in a concurrent 
program. If no synchronization among 
instruction streams exists, then a very large 
number of different instruction interleav¬ 
ings is possible. 

(2) If for performance reasons the order 
of execution of instructions belonging to 
the same instruction stream is different 
from the order implied by the program, 
then an even larger number of instruction 
interleavings is possible. 

(3) If accesses are not atomic (for exam¬ 

ple, if multiple copies of the same data 
exist), as is the case in a cache-based sys¬ 
tem, and if not all copies are updated at the 

same time, then different processors can 
individually observe different interleav¬ 

ings during the same execution. In this case 
the total number of possible execution 

instantiations of a program becomes still 

larger. 

To illustrate the possible types of inter¬ 
leavings, we examine the following three 
program segments to be executed concur¬ 
rently by three processors (initially 
A=B=C= 0, and we assume that a Print 
statement reads both variables indivisibly 
during the same cycle): 


PI P2 P3 

a: A -*-1 c: B -*-1 e:C-l 

b: Print BC d: Print AC f: Print AB 
If the outputs of the processors are con¬ 
catenated in the order P1, P2, and P3, then 
the output forms a six-tuple. There are 64 
possible output combinations. For exam¬ 
ple, if processors execute instructions in 
program order, then the execution inter¬ 
leaving a,b,c,d,e,f is possible and would 
yield the output 001011. Likewise, the 
interleaving a,c,e,b,dj is possible and 
would yield the output 111111. If proces¬ 
sors are allowed to execute instructions out 
of program order, assuming that no data 
dependencies exist among reordered 
instructions, then the interleaving 

b, d,f,e,a,c is possible and would yield the 
output 000000. Note that this outcome is 
not possible if processors execute instruc¬ 
tions in program order only. 

Of the 720 (6!) possible execution inter¬ 
leavings, 90 preserve the individual pro¬ 
gram order. We have already pointed out 
that of the 90 program-order interleavings 
not all six-tuple combinations can result 
(i.e., 000000 is not possible). The question 
remains whether out of the 720 non- 
program-order interleavings all six-tuple 
combinations can result. So far we have 
assumed that the memory system of the 
example multiprocessor is access atomic; 
this means that memory updates affect all 
processors at the same time. In a cache- 
based system such as depicted in Figure 1, 
this may not be the case; such a system can 
be nonatomic if an invalidation does not 
reach all caches at the same time. 

In an atomic system it is easy to show 
that, indeed, not all six-tuple combinations 
are possible, even if processors need not 
adhere to program order. For example, the 
outcome 011001 implies the following: 
Processor PI observes that C has been 
updated and B has not been updated yet. 
This implies that P3 must have executed 
statement e before P2 executed statement 

c. Processor P2 observes that A has been 
updated before C has been updated. This 
implies that PI must have executed state¬ 
ment a before P3 executed statement e. 
Processor P3 observes that B has been 
updated but A has not been updated. This 
implies that P2 must have executed state¬ 
ment c before PI executed statement a. 
Hence, e occurred before c, a occurred 
before e, and c occurred before a. Since 
this ordering is plainly impossible, we can 
conclude that in an atomic system, the out¬ 
come 011001 cannot occur. 

The above conclusion does not hold true 
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Figure 10. Concurrent program for three processors accessing shared variables. 


in a nonatomic multiprocessor. Let us 
assume that the actual execution interleav¬ 
ing of instructions is a,c,e,b,d,f. Let us 
further assume the following sequence of 
events: When PI executes b. Pi’s own 
copy of B has not been updated, but Pi’s 
own copy of Chas been updated. Hence, 
P1 prints the tuple 01. When P2 executes 
d, P2’s own copy of A has been updated, 
but P2’s own copy of C has not been 
updated. Hence, P2 prints the tuple 10. 
When P3 executes /, P3’s own copy of A 
has not been updated, but P3’s own copy 
of B has been updated. Hence, P3 prints 
the tuple 01. The resulting six-tuple is 
indeed 011001. Note that all instructions 
were executed in program order, but other 
processors did not observe them in pro¬ 
gram order. 

We might ask ourselves whether a multi¬ 
processor functions incorrectly if it is capa¬ 
ble of generating any or all of the 
above-mentioned six-tuple outputs. This 
question does not have a definitive answer; 
rather the answer depends on the expecta¬ 
tions of the programmer. A programmer 
who expects a system to behave in a 
sequentially consistent manner will per¬ 
ceive the system to behave incorrectly if it 
allows its processors to execute accesses 
out of program order. The programmer 
will likely find that synchronization pro¬ 
tocols using shared variables will not func¬ 
tion. The difficulty of concurrent 
programming and parallel architectures 
stems from the effort to disallow all inter¬ 
leavings that will result in incorrect out¬ 
comes while not being overly restrictive. 

Systems with atomic accesses. We have 
shown in an earlier work 14 that a neces¬ 
sary and sufficient condition for a system 
with atomic memory accesses to be 
sequentially consistent (the strongest con¬ 
dition for logical behavior) is that memory 
accesses must be performed in the order 
intended by the programmer—i.e., in pro¬ 
gram order. (A Load is considered per¬ 
formed at a point in time when the issuing 
of a Store from any processor to the same 
address cannot affect the value returned by 
the Load. Similarly, a Store on X by 
processor i is considered performed at a 
point in time when an issued Load from 
any processor to the same address cannot 
return a value of X preceding the Store.) 
In a system where such a condition holds, 
we say that storage accesses are strongly 
ordered. 

In a system without caches a memory 
access is performed when it reaches the 
memory system or at any point in time 


when the order of all preceding accesses to 
memory has become fixed. For example, 
if accesses are queued in a FIFO (first in, 
first out) buffer at the memory, then an 
access is performed once it is latched in the 
buffer. When a private cache is added to 
each processor, Stores can also be atomic 
in the case of a bus system because of the 
simultaneous broadcast capability of the 
buses; in such systems the invalidations 
generated by a Store and the Load requests 
broadcast by a processor are latched simul¬ 
taneously by all the controllers (including 
possibly the memory controllers). As soon 
as each controller has taken the proper 
action on the invalidation, the access can 
be considered performed. 

Buffering of access requests and invali¬ 
dations also become possible if the rules 
governing sequential consistency are care¬ 
fully observed. With extensive buffering at 
all levels, and provided that the intercon¬ 
nection and the memory system have suffi¬ 
cient bandwidth, the efficiency of all 
processors may be very high, even if the 
memory access latency is large compared 
to the processor cycle time. Two articles 
present more detailed discussions of the 
buffering of accesses and invalidations in 
cache-based multiprocessors. 7,15 

In a weakly ordered system the condi¬ 
tion of strong ordering is relaxed to include 
accesses to synchronization variables only. 
Synchronization variables must be 
hardware-recognizable to enforce the spe¬ 
cific conditions of strong ordering on 
them. Moreover, before a lock access can 
proceed, all previous accesses to nonsyn¬ 
chronization data must be allowed to “set¬ 
tle.” This means that all shared memory 
accesses made before the lock operation 
was encountered must be completed 
before the lock operation can proceed. In 
systems that synchronize very infre¬ 
quently, the relaxation of strong ordering 


to weak ordering of data accesses can 
result in greater efficiency. For example, 
if the interconnection network is buffered 
and packet-switched, the interface 
between the processor and the network can 
send global memory requests only one at 
a time to the memory if strong ordering is 
to be enforced. The reason for this is that 
in such a network the access time is vari¬ 
able and unpredictable because of con¬ 
flicts; in many cases waiting for an 
acknowledgment from the memory con¬ 
troller is the only way to ensure that global 
accesses are performed in program order. 
In the case of weak ordering the interface 
can send the next global access directly 
after the current global access has been 
latched in the first stage of the interconnec¬ 
tion network, resulting in better processor 
efficiency. However, the frequency of lock 
operations will be higher in a program 
designed for a weakly ordered system. 

Systems with nonatomic accesses. In a 
multiprocessor system with nonatomic 
accesses, it has been shown that the previ¬ 
ous condition for strong ordering of stor¬ 
age accesses (and sequential consistency) 
is not sufficient. 14 

Example 7. In a system with a recombin¬ 
ing network 2 the network can provide for 
access short-circuiting, which combines 
Loads and Stores to the same address 
within the network, before the Store 
reaches its destination memory module. 
For the parallel program in Figure 
10— Sj(X) and L,(X) represent global 
accesses “Store into location Aby proces¬ 
sor and “Load from location X by 
processor respectively—such short- 

circuiting can result in the following 
sequence of events: 

(1) Processor 1 issues a command to 
store a value at memory location A. 
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(2) Processor 2 reads the value written 
by processor 1 “on the fly” before A is 
updated. 

(3) Because of the successful read of A 
in step 2, processor 2 issues a command to 
write a value at memory location B. 

(4) Processor 3 reads the value written 
by processor 2; it reflects the updated B. 

(5) Processor 3 reads memory location 
A and an old value for A is returned 
because the write to A by processor 1 has 
not propagated to A yet. 

Each processor performs instructions in 
the order specified by the programmer, but 
sequential consistency is violated. Proces¬ 
sor 2 implies that step 1 has been com¬ 
pleted by processor 1 when it initiates step 
3. In step 4 processor 3 recognizes that 
implication by successfully reading B. But 
when processor 3 then reads A , it does not 
find the implied new value but rather the 
old value. Consequently, processor 3 
observes an effect of step 1 before it is 
capable of observing step 1 itself. 

Example 2. In a cache-based system 
where memory accesses and invalidations 
are propagated one by one through a 
packet-switched (but not recombining) 
network, the same problem as in the previ¬ 
ous example may occur. Initially, all 
processors have an RO copy of A in their 
cache. 

(1) Processor 1 issues a command to 
store a value at memory location A . Invali¬ 
dations are sent to each processor with a 
copy of A in its cache. (For simplicity we 
assume that the size of a cache block is one 
word.) 

(2) Processor 2 reads the value of A as 
updated by processor 1, because the invali¬ 
dation has reached its cache; processor 1 
writes the data back to main memory and 
forwards a copy to processor 2. 

(3) Because of the successful read of A 
in step 2, processor 2 issues a command to 
write a value at memory location B, send¬ 
ing invalidations for copies of B. 

(4) Processor 3 reads the value written 
by processor 2; it reflects the updated B, 
because the associated invalidations have 
propagated to processor 3. 

(5) Processor 3 reads memory location 
A and an old value for A is returned 
because the invalidation for A caused by 
processor 1 has not yet propagated to the 
third processor’s cache. 

Again each processor executes all 
instructions in program order. Further¬ 
more, a processor does not proceed to 
issue memory accesses before all previous 


invalidations broadcast by the processor 
have been acknowledged. Yet the same 
problem occurs as in the previous example; 
sequential consistency is violated. This is 
the case because invalidations are essen¬ 
tially memory accesses. Because invalida¬ 
tions are not atomic, the system is not 
strongly ordered. 


User interface 

The discussion in this article shows that 
the issues of synchronization, communi¬ 
cation, coherence, and ordering of events 
in multiprocessors are intricately related 
and that design decisions must be based on 
the environment for which the machine is 
destined. Coherence depends on synchro¬ 
nization in some coherence protocols 
because the user has to be aware that syn¬ 
chronization points are the only points in 
time at which coherence is restored. Strict 
ordering of events may be enforced all the 
time (strong ordering) or at synchroniza¬ 
tion points only (weak ordering). 

At the user level most features of the 
physical (hardware) architecture are not 
visible. The instruction set of each proces¬ 
sor and the virtual memory are the most 
important system features visible to the 
programs. Depending on the features of 
the physical architecture that are visible to 
the programmer, the task of programming 
the machine may be more difficult, and it 
may be more difficult to share the machine 
among different users. 

Nontransparent coherence or ordering 
schemes. A sophisticated compiler may 
succeed in efficiently detecting and tagging 
the shared writable data to avoid the 
coherence problem. Such a compiler may 
also be able to make efficient use of syn¬ 
chronization primitives provided at differ¬ 
ent levels. The compiler may be aware of 
access ordering on a specific machine and 
generate code accordingly. It is not clear 
that compiler technology will improve to 
a point where efficient code can be gener¬ 
ated for these different options. 

If a program is written in a high-level 
concurrent language, the facility to specify 
shared writable data may not exist in the 
language, in which case we must still rely 
on the compiler for detecting the minimum 
set of data to tag as noncachable. It should 
be emphasized that perfectly legal pro¬ 
grams in concurrent languages that allow 
the sharing of data, generally will not exe¬ 
cute correctly in a system where events are 
weakly ordered. 


User access to synchronization primi¬ 
tives. Programmers of concurrent applica¬ 
tions may have in their repertoires 
different hardware- or software-controlled 
synchronization primitives. For perfor¬ 
mance reasons it may be advisable to let 
basic hardware-level synchronization 
instructions be directly accessible to users, 
who know their applications and can tai¬ 
lor the synchronization algorithm to their 
own needs. The basic drawback of such a 
policy is the increased possibility of dead¬ 
locks, resulting from programming errors 
or processor failure. Spin-locks and 
suspend-locks consume processor cycles 
and bus cycles. Therefore, such locks 
should never be held for a long time. 
Ideally, a processor should not be inter¬ 
ruptible during the time that it owns a lock; 
for example, one or several processors may 
spin forever on a lock if the process that 
‘ ‘owns” the lock has to be aborted because 
of an exception. In a virtual-machine envi¬ 
ronment the user process does not have 
any control over the interruptibility of the 
processor, and thus a process can be 
preempted while it is owning a lock. This 
will result in unnecessary, resource- 
consuming spinning from all other 
processes attempting to obtain the lock. 

A solution to this problem is the task- 
force scheduling strategy, 1 in which all 
active processes of a multitask are always 
scheduled and preempted together. 
Another solution is the implementation of 
some kind of time-out on spinning. The 
drastic solution to all these problems is to 
involve the operating system in every syn¬ 
chronization or communication, so that it 
can include these mechanisms in its 
scheduling policy to maximize per¬ 
formance. 

M aking a multiprocessor func¬ 
tion correctly can be a simple 
or an extremely difficult 
task. Basic synchronization mechanisms 
can be primitive or complex, wasteful of 
processor cycles or highly efficient. In any 
case the underlying hardware must sup¬ 
port the basic assumptions of the logical 
model expected by the user. In a strongly 
ordered system such an assumption 
usually is that the system behaves in a 
sequentially consistent manner. 

Increased transparency comes at the 
cost of efficiency and increased hardware 
complexity. But traditional and significant 
advantages such as the ability to protect 
users against themselves and other users, 
ease of programming, portability of pro¬ 
grams, and efficient management of 
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shared resources by multiple users are 
strong arguments for the designers of 
general-purpose computers to accept the 
hardware complexity and the negative 
effect on performance. The designers of 
general-purpose machines will probably 
prefer coherence enforcement on the fly in 
hardware, strong ordering of memory 
accesses, and restricted access to synchro¬ 
nization primitives by the user. 

On the other hand, for machines with 
limited access by sophisticated users, such 
as supercomputers and experimental 
multiprocessor systems, the performance 
of each individual task may be of prime 
importance, and the increased cost of 
transparency may not be justified. 

The challenge of the future lies in the 
ability to control interprocess communi¬ 
cation and synchronization in systems 
without rigid structures. Efficient multi¬ 
processing will be provided by systems 
in which synchronization, coherence, and 
logical ordering of events are carefully 
analyzed and blended together harmoni¬ 
ously in the context of efficient hardware 
implementations. It is necessary, however, 
to provide the programmer with a simple 
logical model of concurrency behavior. 
When multiprocessors do not conform to 
the concept of a single logical model, but 
rather must be viewed as a dynamic pool 
of processing, storage, and connection 
resources, the control in software over 
communication and synchronization 
becomes a truly formidable task. The con¬ 
cepts of strong and weak ordering as 
defined in this article correspond to two 
widely accepted models of multiprocessor 
behavior, and we believe that future 
designs will conform to one of the two 
models. □ 
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The Sprite Network 
Operating System 

John K. Ousterhout, Andrew R. Cherenson, Frederick Douglis, Michael N. Nelson, and 
Brent B. Welch 

University of California at Berkeley 


S prite is an experimental network 
operating system under develop¬ 
ment at the University of Califor¬ 
nia at Berkeley. It is part of a larger 
research project called SPUR, whose goal 
is the design and construction of a high- 
performance multiprocessor workstation 
with special hardware support for Lisp 
applications. 1 One of Sprite’s primary 
goals is to support applications running on 
SPUR workstations, but we hope that the 
system will also work well for a variety of 
high-performance engineering worksta¬ 
tions. Currently, Sprite is being used on 
Sun-2 and Sun-3 workstations. 

Driving forces. The motivation for 
building a new operating system came 
from three general trends in computer 
technology: networks, large memories, 
and multiprocessors. 

In an increasing number of research and 
engineering organizations, computing 
now occurs on personal workstations con¬ 
nected by local-area networks. Larger, 
time-shared machines are used only for 
those applications that cannot achieve 
acceptable performance on workstations. 
Unfortunately, workstation environments 



Sprite implements a 
set of kernel calls that 
provide sharing, 
flexibility, and high 
performance to 
networked 
workstations. 


tend to suffer from poor performance and 
difficulties of sharing and administration, 
due to the distributed nature of the sys¬ 
tems. In Sprite, we hope to hide the distri¬ 
bution as much as possible, while 
providing the sharing and communication 
of time-shared machines. 

The second technology trend driving the 
Sprite design is the availability of ever- 
larger physical memories. Today’s 
engineering workstations typically contain 
four to 32 megabytes of physical memory, 


and we expect memories of 100 to 500 
megabytes to be commonplace within a 
few years. We believe that such large mem¬ 
ories will change the traditional balance 
between computation and input/output 
by permitting all of a user’s commonly 
accessed files to reside in main memory. 
The “RAMdisks” available on many com¬ 
mercial personal computers have already 
shown this capability on a small scale. One 
of our goals for Sprite is to manage phys¬ 
ical memory in a way that maximizes the 
potential for file caching. 

The third driving force behind Sprite is 
the imminent arrival of multiprocessor 
workstations. Workstations with more 
than one processor are currently under 
development in several research organiza¬ 
tions (UCB’s SPUR, Digital Equipment 
Corporation’s Firefly, and Xerox’s 
Dragon are a few prominent examples), 
and we expect multiprocessor worksta¬ 
tions to be available from several major 
manufacturers within a few years. We 
hope that Sprite will facilitate the develop¬ 
ment of multiprocessor applications, and 
that the operating system itself will be able 
to take advantage of multiple processors 
in providing system services. 
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Design goals. Our overall goal for Sprite 
is to provide simple, efficient mechanisms 
that capitalize on the three technology 
trends affecting the system’s design. In 
areas where technology factors did not 
suggest special techniques, we modeled the 
system as closely as possible after Berkeley 
Unix. 

The technology trends had only a minor 
impact on the facilities Sprite provides to 
application programs. For the most part, 
Sprite’s kernel calls are similar to those 
provided by the 4.3 BSD version of the 
Unix operating system. However, we 
added three facilities to encourage 
resource sharing: a transparent network 
file system, a simple mechanism for shar¬ 
ing writable memory between processes on 
a single workstation, and a mechanism for 
migrating processes between workstations 
to take advantage of idle machines. 

Although the technology trends did not 
have a large effect on Sprite’s kernel inter¬ 
face, they did suggest dramatic changes in 
the kernel implementation, relative to 
Unix. This is not surprising, since net¬ 
works, large memories, and multiproces¬ 
sors were not important issues in the early 
1970s when the Unix kernel was designed. 
We developed the Sprite kernel from 
scratch, rather than modifying an existing 
Unix kernel. Some interesting features of 
the kernel implementation are 

• The kernel contains a remote proce¬ 
dure call (RPC) facility that allows each 
workstation’s kernel to invoke operations 
on other workstations. The RPC mecha¬ 
nism is used extensively in Sprite to imple¬ 
ment other features, such as the network 
file system and process migration. 

• Although the Sprite file system is 
implemented as a collection of domains on 
different server machines, it appears to 
users as a single hierarchy shared by all 
workstations. Sprite uses a simple mech¬ 
anism called prefix tables to manage the 
name space; these dynamic structures 
facilitate system administration and recon¬ 
figuration. 

• To achieve high performance in the 
file system, and also to capitalize on large 
physical memories. Sprite caches file data 
on both server and client machines. A sim¬ 
ple cache consistency mechanism guaran¬ 
tees that applications running on different 
workstations always use the most up-to- 
date versions of files, in exactly the same 
fashion as if the applications were execut¬ 
ing on a single machine. 

• The virtual memory system uses ordi¬ 
nary files for backing storage; this simpli¬ 
fies implementation, facilitates process 


migration, and may even improve perfor¬ 
mance relative to schemes based on a 
special-purpose swap area. Sprite retains 
the code segments for programs in main 
memory, even after the programs are com¬ 
plete, to allow quick start-up when pro¬ 
grams are reused. Finally, the virtual 
memory system negotiates with the file sys¬ 
tem over physical memory use, permitting 
the file cache to be as large as possible 
without degrading virtual memory per¬ 
formance. 

• Sprite guarantees that processes 
behave the same whether migrated or not. 
This is achieved by designating a home 
machine for each process and forwarding 
location-dependent kernel calls to the 
process’ home machine. 

Application interface 

Sprite’s application interface contains 
little that is new. Kernel calls are very simi¬ 
lar to those provided by the Berkeley ver¬ 
sions of Unix. Indeed, we have ported 
many traditional Unix applications to 
Sprite with relatively little effort. 

Three unusual aspects of the application 
interface can be summed up in one word: 
sharing. First, the Sprite file system allows 
sharing of all disk storage and I/O devices 
in the network by all processes, so they 
need not worry about machine bound¬ 
aries. Second, the virtual memory mech¬ 
anism allows sharing of physical memory 
between processes on the same worksta¬ 
tion, so they can extract the highest possi¬ 
ble performance from multiprocessors. 
Third, Sprite implements process migra¬ 
tion, which allows job offloading to idle 
workstations and, thereby, sharing of 
processing power. 

File system. Almost all modern network 
file systems, including Sprite’s, have the 
same ultimate goal: network transparency. 
Network transparency means that users 
should be able to manipulate files in the 
same ways they did under time-sharing on 
a single machine; the distributed nature of 
the file system and the techniques used to 
access remote files should be invisible to 
users under normal conditions. MIT’s 
Locus system was one of the first to make 
transparency an explicit goal 2 ; other file 
systems with varying degrees of trans¬ 
parency are Carnegie Mellon’s Andrew 3 
and Sun’s NFS. 4 

Most network file systems fail to meet 
the transparency goal in one or more ways. 
The earliest systems (and even some later 


systems, such as 4.2 BSD) allowed remote 
file access only with a few special programs 
(for example, rep in 4.2 BSD); most appli¬ 
cation programs could only access files 
stored on local disks. Second-generation 
systems, such as Apollo’s Aegis, 5 allow 
any application to access files on any 
machine in the network, but special names 
must be used for remote files (for example, 
“file” for a local file, but “[ivyjfile” for 
a file stored on the Ivy server). Third- 
generation network file systems, such as 
Locus, Andrew, NFS, and Sprite, provide 
name transparency —that is, file location 
is not indicated directly by name, and 
groups of files can be moved from one 
machine to another without changing their 
names. 

Most third-generation systems still have 
some nontransparent aspects. For exam¬ 
ple, in Andrew and NFS only a portion of 
the file system hierarchy is shared; each 
machine must also have a private partition 
that is accessible only to that machine. In 
addition, Andrew and NFS do not permit 
applications running on one machine to 
access I/O devices on other machines. 
Locus appears to be alone among current 
systems in providing complete file trans¬ 
parency. 

Sprite, like Locus, provides complete 
transparency, so applications running on 
different workstations see the same 
behavior they would see if all the applica¬ 
tions were executing on a single time- 
shared machine. A single file hierarchy is 
uniformly accessible to all workstations. 
Although it is possible to determine where 
a file is stored, that information is not 
needed in normal operation. There are no 
special programs for operating on remote 
files, as opposed to local ones, and no 
operations that can be used only on local 
files. Sprite also provides transparent 
access to remote I/O devices. Like Unix, 
Sprite represents devices as special files; 
unlike most versions of Unix, Sprite allows 
any process to access any device, regard¬ 
less of device location. 

Shared address spaces. The early ver¬ 
sions of Unix did not permit memory shar¬ 
ing between user processes, except for 
read-only code. Each process had private 
data and stack segments, as shown in Fig¬ 
ure 1. Since then, extensions to allow read- 
write memory sharing have been imple¬ 
mented or proposed for several versions of 
Unix, including System V, SunOS, Ber¬ 
keley Unix, and Mach. 

There are two reasons for providing 
shared memory. First, using a collection of 
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processes in a shared address space is the 
most natural way to program many appli¬ 
cations. It is particularly convenient when 
an application consists of mostly indepen¬ 
dent subactivities (for example, one proc¬ 
ess to respond to keystrokes and another 
to respond to packets arriving over a net¬ 
work); the shared address space allows 
them to cooperate to achieve a common 
goal (for example, managing a collection 
of windows on a screen). The second moti¬ 
vation for shared memory is the advent of 
multiprocessors. Decomposing an appli¬ 
cation into pieces that can be executed con¬ 
currently requires rapid communication 
between pieces. The faster the communi¬ 
cation, the greater the degree of concur¬ 
rency that can be achieved. Shared 
memory provides the fastest possible com¬ 
munication, hence the greatest opportu¬ 
nity for concurrent execution. 

Sprite provides a particularly simple 
form of memory sharing; when a process 
invokes the Proc_Fork kernel call to cre¬ 
ate a new process, it may request that the 
new process share the parent’s data seg¬ 
ment (see Figure 2). The stack segment is 
still private to each process; it contains 
procedure invocation records and private 
process data. For simplicity, Sprite’s 
mechanism provides all-or-nothing shar¬ 
ing; a process cannot share part of its data 
segment with one process and part of it 
with another. 

We expect multiprocess applications to 
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Figure 1. The organization of virtual memory as seen by user processes in tradi¬ 
tional Unix (left) and Sprite (right). In both systems there are three distinct seg¬ 
ments. The lower portion of the data segment contains static data known at 
compile time, and the upper portion expands to accommodate dynamically allo¬ 
cated data. In Unix, processes may share code, but not data or stack. In Sprite, the 
data segment may be shared between processes, including both statically allocated 
and dynamic data. Private static data may be stored at the top of the stack 
segment. 


synchronize using hardware mutual- 
exclusion instructions (for example, test- 
and-set) directly on shared memory. In 
most cases it will not be necessary to 
invoke the kernel, so synchronization can 
be accomplished in just a few instructions. 
The kernel participates only when it is 
necessary to delay process execution (for 
example, to wait for a lock to be released). 
For these situations, Sprite provides ker¬ 
nel calls that put a process to sleep and 


wake it up later. This permits efficient 
implementation of synchronization 
primitives. 

Process migration. In an environment 
that has a workstation for each person, 
many machines will be idle at any given 
time. To allow users to harness this idle 
computing power, Sprite provides a new 
kernel call, Proc_Migrate, that will move 
a process or group of processes to an idle 
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Figure 2. The Unix fork operation (a) creates a new process that shares code with its parent while using private copies of the 
data and stack segments. Sprite provides both the traditional fork and a shared fork (b) in which the child shares its parent’s 
data as well as code. 
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machine. Processes sharing a heap seg¬ 
ment must migrate together. Sprite keeps 
track of which machines are idle and 
selects one as the target for the migration. 
The fact that a process has migrated is 
transparent both to the migrated process 
and to the user, as described below. The 
only noticeable difference after migration 
will be a reduction in the home machine’s 
load. 

Initially, we expect migration to be used 
in two ways. First, shell commands for 
manual migration will allow users to 
migrate processes in much the same way 
the Unix shell allows users to place 
processes in the background. Second, a 
new version of the Unix Make utility, 
called Pmake, recompiles programs when 
their source files change. Make invokes 
recompilations sequentially, but Pmake is 
organized to invoke multiple recompila¬ 
tions concurrently, using process migra¬ 
tion to offload the compilations to idle 
machines. We hope to see more and more 
automatic uses of migration, like Pmake, 
in the future. 

The idea of moving work to idle 
machines is not a new one. Unfortunately, 
the most widely available facilities (for 
example, the rsh command of 4.2 BSD 
Unix and the rex facility of Sun’s Unix) 
provide only remote invocation, which is 
the ability to initiate new processes on 
other machines, but not the ability to move 
processes once they have started execu¬ 
tion. Process migration, which allows 
processes to be moved at any time, has 
been implemented in several systems (for 
example. Locus, 2 V, 6 and Accent 7 ) but is 
not widely available. For Sprite, we 
decided to implement process migration. 
We think the additional flexibility migra¬ 
tion provides is particularly important in 
a workstation environment. For example, 
if remote invocation is used to offload 
work onto an idle machine and then the 
machine’s user returns, either the foreign 
processes have to be killed or the 
machine’s user receives a degraded 
response until the foreign processes are 
complete. In Sprite, the foreign processes 
can be migrated away. 

One of the most important attributes of 
Sprite’s migration mechanism is its trans¬ 
parency, both to the process and to the 
user. When migrated, a process will pro¬ 
duce exactly the same results as if it were 
not migrated; Sprite preserves the environ¬ 
ment of the process as it migrates, includ¬ 
ing files, working directory, device access, 
environment variables, and anything else 
that could affect process execution. In 


addition, a migrated process appears still 
to be running on the user’s home machine; 
it will appear in listings of processes on that 
machine and can be stopped, killed, or 
debugged just like the user’s other 
processes. In contrast, rsh does not pre¬ 
serve the working directory and other 
aspects of the environment, and neither 
rsh nor rex allows a remotely executing 
process to be examined or manipulated in 
the same fashion as local processes. Other 
implementations of process migration 
tend not to provide complete transparency 
to users, although they do provide com¬ 
plete transparency to the migrated 
processes. (How Sprite achieves execution 
transparency is described in a later 
section.) 

Basic kernel structure 

Application programs invoke kernel 
functions via a collection of kernel calls. 
Sprite’s basic flow of control in a kernel 
call is similar to that in Unix: user 
processes execute “trap” instructions to 
switch to the supervisor state, and the ker¬ 
nel executes as a privileged extension of the 
user process, using a small per-process ker¬ 
nel stack for procedure invocation within 
the kernel. 

Two features of Sprite’s basic kernel 
structure support multiprocessor and net¬ 
work operation. First, a multithreaded 
synchronization structure allows the Sprite 
kernel to run efficiently on multiproces¬ 
sors. Second, a remote procedure call 
facility allows kernels to invoke operations 
remotely over the network. 

Multithreading. Many operating system 
kernels, including Unix, are single- 
threaded, which means that a single lock 
is acquired when a process calls the kernel 
and released when the process puts itself 
to sleep or returns to user state. In these 
systems, processes are never preempted 
while executing kernel code, except by 
interrupt routines. The single-threaded 
approach simplifies kernel implementa¬ 
tion by eliminating many potential syn¬ 
chronization problems between processes. 
Unfortunately, it does not adapt well to a 
multiprocessor environment. With more 
than a few processors, contention for the 
single kernel lock will limit system per¬ 
formance. 

In contrast, the Sprite kernel is mul¬ 
tithreaded, which means that several 
processes may execute in the kernel at the 
same time. The kernel is organized in a 


monitor-like style with many small locks, 
instead of a single overall lock, protecting 
individual modules or data structures. 
Many processes may execute in the kernel 
simultaneously as long as they do not 
attempt to access the same monitored code 
or data. The multithreaded approach 
allows Sprite to run more efficiently on 
multiprocessors, but the multiplicity of 
locks makes the kernel more complex and 
slightly less efficient since many locks may 
have to be acquired and released over the 
lifetime of each kernel call. 

Remote procedure calls. In designing 
Sprite for a network of workstations, one 
of our most important goals was to pro¬ 
vide a simple, efficient way for the kernels 
of different workstations to invoke each 
others’ services. The mechanism we chose 
is a kernel-to-kernel RPC facility similar 
to the one described by Birrell and Nel¬ 
son. 8 We chose RPC rather than a mes¬ 
sage style because RPC provides a simple 
programming model (remote operations 
appear just like local procedure calls) and 
because the RPC approach is particularly 
efficient for request-response transac¬ 
tions, which we expected to be the most 
common form of interaction between 
kernels. 

The RPC implementation consists of 
stubs and RPC transport, as shown in Fig¬ 
ure 3. Together they hide the fact that the 
calling procedure and the called procedure 
are on different machines. Each remote 
call has two stubs, one on the client work¬ 
station and one on the server. The client 
stub copies its arguments into a request 
message and returns values from a result 
message, so the calling procedure is not 
aware of the underlying message commu¬ 
nication. The server stub passes arguments 
from the incoming message to the desired 
procedure and packages results from the 
procedure, so the called procedure is not 
aware that its real caller is on a different 
machine. Birrell and Nelson modified their 
compiler to generate the stubs automati¬ 
cally from a specification of procedure 
interfaces. To avoid changing our C com¬ 
piler, we hand-generated the stubs for the 
40 or so remote operations used in the 
Sprite kernel. Although this was workable, 
it would have been more convenient if an 
automated stub-generator had been 
available. 

The second part of the RPC implemen¬ 
tation is RPC transport. It delivers mes¬ 
sages across the network and assigns 
incoming requests to kernel processes that 
execute the server stubs and called proce- 
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Figure 3. Sprite’s remote procedure call mechanism makes it appear as if a remote procedure can be invoked directly (a). The 
actual situation (b) is that stub procedures copy procedure arguments and results into and out of messages, and a transport 
mechanism delivers the messages reliably and assigns server processes to requests. 


dures. The goal of RPC transport is to pro¬ 
vide the most efficient possible 
communication between the stubs while 
ensuring that messages are delivered relia¬ 
bly. Sprite’s RPC transport uses two tech¬ 
niques to gain efficiency: implicit 
acknowledgments and fragmentation. 

Since network transmission is not per¬ 
fectly reliable, each request and response 
message must be acknowledged; if no 
acknowledgment is received within a 
reasonable time, the sender retransmits. 
To reduce the overhead associated with 
processing acknowledgment packets, 
Sprite uses the scheme described by Birrell 
and Nelson, where each request or 
response message serves as an implicit 
acknowledgment for the previous response 
or request message from that client, 
respectively. In the common case of short, 
closely spaced operations, only two 
packets are transmitted for each remote 
call: one for the request and one for the 
response. 

The simplest way to implement RPC is 
to limit the total size of the arguments or 
results for any given RPC so that each 
request and response message can fit into 
a single network packet. Unfortunately, 
the maximum allowable size for a network 


packet is relatively small (about 1500 bytes 
for Ethernet), so this approach would 
result in high overhead for bulk transfers. 
The delays associated with sending a 
request, dispatching to a server process, 
and returning a response would be 
incurred for each 1500 bytes. Since remote 
file access is one of RPC’s most common 
uses, we were unwilling to accept this per¬ 
formance limitation. 

Sprite’s RPC mechanism differs from 
the Birrell-Nelson scheme in that it uses 
fragmentation to ship large blocks of data 
(up to 16 kilobytes) in a single remote oper¬ 
ation. If a request or reply message is too 
long to fit in a single packet, RPC trans¬ 
port breaks the message into multiple 
packets (fragments), which it transmits in 
order without waiting for acknowledg¬ 
ment. The receiving RPC transport reas¬ 
sembles the fragments into a single large 
message. A single acknowledgment for all 
the fragments uses the implicit 
acknowledgment scheme described above. 
When packets are lost in transmission, the 
acknowledgment indicates which frag¬ 
ments have been received so that only lost 
fragments are retransmitted. 

Sprite kernels trust each other, and we 
assume that the network wire is physically 


secure (all workstations on the network 
must run the Sprite kernel or some other 
trustworthy software). Thus, the RPC 
mechanism does not use encryption, nor 
do the kernels validate RPC operations 
except to prevent user errors and detect 
system bugs. The RPC mechanism is used 
only by the kernels and is not directly visi¬ 
ble to user applications. 

Figure 4 shows the measured perfor¬ 
mance of the Sprite RPC mechanism. Fig¬ 
ure 4a shows that the minimum round-trip 
time for the simplest possible RPC is about 
2.8 milliseconds between Sun-3/75 work¬ 
stations, with an additional 1.2 milli¬ 
seconds for each kilobyte of data. Figure 
4b shows that throughputs greater than 
700 kilobytes per second (nearly 60 percent 
of the total Ethernet bandwidth of 10 
megabits per second) can be achieved 
between two workstations if each RPC 
transfers a large amount of data. Without 
fragmentation (at most 1500 bytes trans¬ 
mitted per RPC) the throughput is reduced 
by more than a factor of two. The meas¬ 
urements in Figure 4 are for operations 
between kernels. User-visible performance 
is slightly worse; for example, a user proc¬ 
ess can achieve a throughput of only 475 
kilobytes per second when it reads a file 
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Figure 4. Measured performance of Sprite’s remote procedure call mechanism between Sun-3/75 workstations. The test con¬ 
sisted of one kernel invoking a remote procedure in another kernel, passing to it the contents of a variable-size array as an 
argument. The called procedure returned immediately. Part (a) shows the round-trip time for an individual RPC as a function 
of the amount of data passed to the remote procedure; (b) shows the throughput when repeated RPCs are made. Larger trans¬ 
fers, which use fragments on 1500-byte boundaries, are most efficient. The jumps in the curves occur at the points where addi¬ 
tional packets become necessary. 


that is cached in the main memory of a 
remote server and the kernel makes four- 
kilobyte RPC requests. 

Managing the file name 
space—prefix tables 

In designing the Sprite file system for a 
network environment, we were particu¬ 
larly concerned about two implementation 
issues: how to manage the file name space 
in a way that simplifies system administra¬ 
tion, and how to manage the file data in a 
way that provides high performance. Fur¬ 
thermore, we felt that it was important to 
provide easy administration and high per¬ 
formance without compromising users’ 
ability to share files. 

To users, the Sprite file system is a sin¬ 
gle hierarchy, just as in time-shared Unix. 
To system administrators, the file system 
is a collection of domains, which are simi¬ 
lar to file systems in Unix. Each domain 
contains a tree-structured portion of the 
overall hierarchy. The domains are joined 
into a single hierarchy by overlaying the 
leaves of some domains with the roots of 
other domains as illustrated in Figure 5. 
(In Unix terms, the subdomains are 


mounted on their parents; the leaves where 
mounting occurs, such as “/a” in Figure 
5, are called mount points.) As the oper¬ 
ating system traverses the components of 
a file name during name lookup, it must 
move automatically from domain to 
domain to keep the domain boundaries 
from being visible to users. 

The interesting naming issues are how to 
keep track of the domain structure and 
how to handle file names that cross 
domain boundaries. These issues are par¬ 
ticularly interesting in a network environ¬ 
ment where the domains may be stored on 
different servers and where the server con¬ 
figuration may change frequently. Unix 
and most of its derivatives (such as NFS) 
use static mount tables to keep track of 
domains; the mount tables are established 
by reading a local configuration file at 
boot-time. This makes it difficult for the 
systems to respond to configuration 
changes. In our NFS clusters, for example, 
any change to the domain structure typi¬ 
cally requires each user to modify the con¬ 
figuration file on their workstation and 
reboot. Even in small clusters we have 
found that such changes occur distress¬ 
ingly often. 


In Sprite, we use a more dynamic 
approach to managing the domain struc¬ 
ture, which we call prefix tables. Each cli¬ 
ent machine’s kernel maintains a private 
prefix table. Each entry in a prefix table 
corresponds to a domain; it gives the full 
name of the top-level directory in the 
domain (that is, the common prefix shared 
by the names of all files in the domain), the 
name of the server on which that domain 
is stored, and an additional token to pass 
to the server to identify the domain (see 
Table 1). Prefix tables are not normally 
visible to user processes. 

Locating a file. In Sprite, as in Unix, 
application programs refer to files by giv¬ 
ing either an absolute path name for the 
file (one starting at the file system root, 
such as “/d/k/p/r” in Figure 5) or a rela¬ 
tive path name, which is interpreted as 
starting at a previously specified working 
directory (if the working directory is 
“/d/k/p” in Figure 5, then the relative 
name “r” refers to the same file as 
“/d/k/p/r”). To look up an absolute path 
name, a client kernel matches the name 
against all entries in its prefix table and 
chooses the entry with the longest match- 
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Figure 5. Although the Sprite file system behaves as if it were a single hierarchy (a), 
it is actually divided up into domains (b). Each domain may be stored on a 
different server. 


ing prefix. In the example of Figure 5, the 
file name “/d/k/p/r” will match three 
entries in the table, of which the entry for 
server Z has the longest prefix. The client 
strips the prefix from the file name and 
uses the RPC facility to send the remainder 
of the name (“p/r”) to the server, along 
with the token from the prefix table en¬ 
try (5). The server uses the token to locate 
the root directory of the domain, looks up 
the remainder of the file name, and replies 
with a token identifying the file. The cli¬ 
ent can then issue read, write, and close 
requests by making RPCs to the server 
with the file’s token. 

Sprite handles working directories by 
opening the working directory and storing 
its token and server address as part of the 
process’ state. When a file name is speci¬ 
fied relative to the working directory, the 
client kernel uses the token and server 
address corresponding to the working 
directory rather than those from a prefix 
table entry. Thus, absolute and relative 
path name lookups appear identical to the 
server. 

There are several cases where the initial 
server that receives a file name cannot 
completely process the name. These cor¬ 
respond to situations where the file’s name 
crosses a domain boundary. For example, 
components in a name (which refer 
to the parent directory) could cause it to 
ascend back up the hierarchy and out 
the top of the domain; or the name could 
refer to a symbolic link containing an 
absolute file name for a different domain; 
or a relative path name could start at the 
current working directory and descend 
into a new domain. In each of these cases, 
the initial server processes as many com¬ 
ponents of the file name as it can, then 
returns a new name to the client instead of 
a file token. The client takes the new name, 
processes it with its prefix table, and sends 
it to a new server. This process repeats 
until the name is completely resolved (see 
Welch and Ousterhout 9 for details). 

The prefix approach bypasses the root 
domain (and its server) when looking up 
absolute names of files in nonroot 
domains. Since a large fraction of all name 
lookups involves absolute path names, we 
expect this approach to reduce the load on 
the root server and increase the scalability 
of the system relative to schemes that 
require root server participation for every 
absolute path name. It may also let the sys¬ 
tem provide limited service even when the 
root server is down. 

Managing prefix tables. One of the 


greatest advantages of prefix tables is that 
they are created dynamically and updated 
automatically when the system configura¬ 
tion changes. To add a new entry to its pre¬ 
fix table, a client broadcasts a prefix name 
to all servers. The server storing the 
domain replies with its address and the 
token corresponding to the domain. The 
client uses this information to create a new 
prefix table entry. Initially, each client 
starts out with an empty prefix table and 
broadcasts to find the entry for “/.” As 
it uses more files, it gradually adds entries 
to its prefix table. 

How does a client know when to add a 
new prefix to its table? The file at the 
mount point for each domain is a special 


Table 1. A prefix table corresponding 
to the domain structure of Figure 5.* 



‘Prefix tables are loaded dynamically, so 
they need not hold complete file information 
at any given time. 

link, called a remote link, which identifies 
the file as the mount point for a new 
domain. For example, in Figure 5 the file 
“/d/k” in server Y’s domain is a remote 
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Figure 6. Caches in the Sprite file system. When a process makes a file access, it is 
presented first to the cache of the process’ workstation (file traffic). If not satisfied 
there, the request is passed either to a local disk, if the file is stored locally (disk 
traffic), or to the server where the file is stored (server traffic). Servers also main¬ 
tain caches to reduce their disk traffic. 


link. A remote link is similar to a symbolic 
link in that it stores a file name; for remote 
links, this is the prefix name (that is, the 
file’s absolute name). Whenever a remote 
link is encountered in file name lookup, 
the server returns to the client the prefix 
name and the remainder of the name being 
looked up. The client uses the broadcast 
protocol to make a new prefix table entry 
and then reprocesses the remainder of the 
name. Remote links do not store any net¬ 
work address information; they simply 
indicate the presence of a domain. This 
feature permits the system to adapt quickly 
to changes in configuration. 

Prefix table entries are treated as hints 
and are adjusted automatically as the sys¬ 
tem configuration changes. When a client 
sends an open request to a server, it is pos¬ 
sible for the request to fail with a timeout 
(if the server has crashed) or a rejection (if 
the server no longer stores the domain). In 
either case, the client invalidates the pre¬ 
fix table entry for the domain and rebroad¬ 
casts. If the domain has moved, the new 
server will respond to the rebroadcast, and 
the client will establish a new prefix table 
entry and retry the open. In this case, the 
configuration change will be invisible to 
user processes. If the server has crashed, 
then the broadcast will timeout; each addi¬ 
tional open will also broadcast and 
timeout. During the time the server is 
down, user processes will receive errors 
analogous to disk-off-line errors in time- 
shared Unix. Eventually, the domain will 
become available again, and the next open 
will reestablish the prefix table entry. 


Adding a new domain to the file system 
requires only adding a remote link at the 
mount point for the domain and arrang¬ 
ing for the server to respond to requests. 

Managing file data— 
client and server caches 

The Sprite file system is implemented 
using large caches of recently used file 
blocks stored in the main memories of 
both clients and servers. The caches pro¬ 
vide two benefits that are especially impor¬ 
tant when most of the workstations are 
diskless. First, the caches improve file sys¬ 
tem performance by eliminating disk 
accesses and network transactions. Sec¬ 
ond, they reduce the loading on the net¬ 
work and the servers, which increases the 
scalability of the system. Sprite’s caches 
use a consistency protocol that allows 
applications on different workstations to 
share files just as if they were running on 
a single time-sharing system. 

Basic cache design. Each client and 
server workstation maintains a large cache 
of recently accessed file blocks, as shown 
in Figure 6. The caches are organized on 
a block basis, rather than a whole-file basis 
as in the Andrew file system, 3 and are 
stored in main memory rather than on a 
local disk. Blocks are currently four kilo¬ 
bytes. Each block in the cache is identified 
by a token for a file and a block location 
within the file. When the Fs_Read kernel 
call is invoked to read a block of a file, the 


kernel first checks its cache and returns the 
information from the cache if it is present. 
If the block is not in the cache, the kernel 
reads it from disk (if the file is on a local 
disk) or requests it from a server; in either 
case, the block is added to the cache, 
replacing the least-recently used block. If 
the block is requested from a server, the 
server checks its own cache before issuing 
a disk I/O and adds the block to its cache 
if the block was not already there. 

Sprite uses a delayed-write approach to 
handle file writes. When an application 
issues an Fs_Write kernel call, the kernel 
simply writes the block into its cache and 
returns to the application. The block is not 
written through to the disk or server until 
it is ejected from the cache or 30 seconds 
have elapsed since the block was last modi¬ 
fied. This policy is similar to the one used 
in time-shared Unix. It means some recent 
work may be lost in a system crash, but it 
provides much higher performance to 
applications than a policy based on write- 
through, since the application can con¬ 
tinue without waiting for information to 
be flushed to disk. For applications with 
special reliability requirements, Sprite pro¬ 
vides a kernel call to flush one or more 
blocks of a file to disk. 

Cache consistency. When clients cache 
files, a consistency problem arises: What 
happens if one client modifies a file that is 
cached by other clients? Can subsequent 
references to the file by the other clients 
return “stale” data? Most network file 
systems, such as Sun’s NFS, provide only 
limited guarantees about consistency. In 
NFS, for example, other clients with the 
file open may see stale data until they close 
the file and reopen it. Sprite guarantees 
consistency; each Fs_Read kernel call 
always returns the most up-to-date data 
for a file, regardless of how the file is being 
used around the network. This means that 
application programs running on different 
workstations under Sprite behave as if they 
were all running on a single, time-shared 
Unix system. 

To simplify the implementation of 
cache consistency, we considered two sep¬ 
arate cases. The first case is sequential 
write-sharing, where a file is modified by 
one workstation, read later by another 
workstation, but never open on both 
workstations at the same time. We expect 
this to be the most common form of write¬ 
sharing. The second case is concurrent 
write-sharing, where one workstation 
modifies a file while it is open on another 
workstation. Our solution to this situation 
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Figure 7. Client degradation and network traffic as a function of maximum client cache size for diskless Sun-3/75s with client 
caches using an unloaded Sun-3/180 file server. For each point the cache size was allowed to vary up to the given maximum. 
Part (a) plots degradation, which is the additional time required by a diskless workstation to complete the benchmark, relative 
to the time to complete the benchmark with a local disk and four-megabyte cache; (b) plots network traffic, including bytes 
transmitted in packet headers and control packets as well as file data. 


is more expensive, but we do not expect it 
to occur very often. 

Sprite uses version numbers to handle 
sequential write-sharing. When a client 
opens a file, the server returns the file’s 
current version number, which the client 
compares to the version number associated 
with its cached blocks for the file. If they 
are different, the file must have been modi¬ 
fied recently on some other workstation. 
In this case, the client discards all cached 
blocks for the file and reloads its cache 
from the server when the blocks are 
needed. Because of Sprite’s delayed-write 
policy, the server does not always have cur¬ 
rent file data (the last writer need not have 
flushed dirty blocks back to the server 
when it closed the file). Servers handle this 
situation by keeping track of the last writer 
for each file; when a client other than the 
last writer opens the file, the server forces 
the last writer to write all its dirty blocks 
back to the server’s cache. This guarantees 
that the server has up-to-date file informa¬ 
tion whenever a client needs it. 

For concurrent write-sharing, where the 
file is open on two or more workstations 
and at least one of them is writing the file, 
Sprite disables client caching for that file. 


When the server receives an open request 
that will cause concurrent write-sharing, it 
flushes dirty blocks back from the current 
writer (if any) and notifies all clients hav¬ 
ing the file open that they should not cache 
the file anymore. Cache disabling is done 
on a file-by-file basis, and only when con¬ 
current write-sharing occurs. A file may be 
cached simultaneously by several active 
readers. 

There are two potential disadvantages 
to Sprite’s cache consistency mechanism. 
First, it results in substantially slower file 
access when caching has been disabled. 
Fortunately, measurements and simula¬ 
tions in Nelson et al. 10 and Ousterhout et 
al.“ show that files tend to be open for 
only short periods and are rarely write- 
shared, so cache disabling seldom occurs. 
Second, the Sprite approach depends on 
the fact that the server is notified whenever 
a file is opened or closed. This prohibits 
performance optimizations (such as name 
caching) in which clients open files with¬ 
out contacting the files’ servers. Our 
benchmark results in Nelson et al. 10 sug¬ 
gest that such optimizations would provide 
little performance improvement. 

It is important to distinguish between 


consistency and correct synchronization. 
Sprite’s mechanism provides consistency; 
each read will return the most up-to-date 
data. However, the cache consistency 
mechanism will not guarantee that appli¬ 
cations perform their reads and writes in 
a sensible order. For this to occur, appli¬ 
cations must synchronize their actions on 
the file using the Fs_Lock system call or 
other available communication mechan¬ 
isms. The cache consistency provided by 
Sprite simply eliminates the network issues 
and reduces the problem to that of time¬ 
sharing systems. 

File system performance. To measure 
the benefits of caching, we ran a series of 
file-intensive benchmark programs on 
Sun-3/75 workstations. A single 
Sun-3/180 file server was used for all cli¬ 
ent I/O and paging traffic. Because the 
benchmarks do not involve file sharing, 
they do not measure the overhead 
associated with cache consistency. (For 
descriptions of the benchmarks and addi¬ 
tional performance measurements, see 
Nelson et al. 10 ) 

Figure 7 shows that diskless worksta¬ 
tions with caches of a few megabytes can 
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Figure 8. Effects of server contention when multiple diskless clients ran the most intensive benchmark (Andrew) simultane¬ 
ously on different files using Sun-3/75 workstations. Andrew, written by M. Satyanarayanan, 3 is a composite benchmark that 
includes directory searches, file copying, version checking, and compilation. Part (a) shows the additional time required by 
each diskless client to complete the benchmark, relative to a single client running with local disk and cache; (b) shows server 
CPU use. When client caches were enabled, they were allowed to grow to four megabytes. 
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Figure 9. Sprite’s paging structure. The code is paged in on-demand from the proc¬ 
ess’ object file; since the code is read-only, it need not be written to backing storage 
and can be reloaded from the object file when needed. An ordinary file is used to 
back each data and stack segment. Initialized portions of the data segment are read 
in from the object file on first reference, then written to the backing file during 
page replacement and reused from there. For the stack segment and the uninitial¬ 
ized portions of the data segment, pages are filled with zeros on first reference, 
then paged to and from the backing files. 


achieve performance within one to 12 per¬ 
cent of workstations with local disks, 
whereas diskless workstations without 
caches typically run 10 to 40 percent slower 


than workstations with disks. It also shows 
that client caching reduces network traf¬ 
fic by a factor of four or more. Without 
client caching, we believe that Ethernet’s 


10-megabit-per-second bandwidth will be 
a major bottleneck for next-generation 
workstations with five to 10 million 
instructions per second of processing 
power (for example, SPUR or the Sun-4 
family). Even with client caching, faster 
networks will be needed to support the 
next generation of workstations after that. 

Figure 8 shows that client caching 
reduces the server load by about a factor 
of two and suggests that a single server 
could support 10 or more active clients 
without excessive performance degrada¬ 
tion. Normal users are rarely as active as 
the benchmark in Figure 8; Howard et 
al. 3 and Nelson et al. 10 estimate that one 
instance of the benchmark presents a load 
equivalent to at least five average users. 
This suggests that a Sun-3/180 Sprite file 
server can support at least 50 user work¬ 
stations. 

In comparisons with Sun’s NFS, Sprite 
completed the Andrew benchmark 30 per¬ 
cent faster and generated only about one- 
fourth the server load. Since our NFS 
servers can support 10 to 20 clients, the 
NFS comparison supports our estimate of 
at least 50 clients per Sprite file server. (See 
Nelson et al. 10 for more information on 
the NFS comparison.) 
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Virtual memory 

Sprite’s virtual memory implementation 
is traditional in many respects. For exam¬ 
ple, it uses a “clock” algorithm variation 
for its page replacement mechanism and 
uses a straightforward extension of the 
time-shared Unix mechanism to provide 
shared read-write data segments. These 
and other aspects of the virtual memory 
system are described in detail by Nelson. 12 

This section focuses on three aspects of 
the virtual memory implementation where 
we intentionally deviated from Unix to 
better use networks and large physical 
memories. First, Sprite uses ordinary files 
for backing storage to simplify process 
migration, to share backing storage 
between workstations, and to capitalize on 
server caches. In addition. Sprite provides 
“sticky segments” and a dynamic trade¬ 
off of physical memory between the virtual 
memory system and the file cache; these 
mechanisms were implemented to make 
the best possible use of physical memory 
as a cache for programs and files. 

Backing storage. Backing storage is the 
portion of disk used to hold pages that 
have been swapped out of physical mem¬ 
ory. Most versions of Unix use a special 
disk partition for backing storage and 
manage that partition with special 
algorithms. In networked Unix systems, 
each machine has its own private disk par¬ 
tition for backing storage. In contrast, 
Sprite uses ordinary files, stored in the 
network file system, for backing storage. 
A separate backing file is used for each 
data and stack segment, as illustrated in 
Figure 9. Each workstation is assigned a 
separate directory in which to create back¬ 
ing files for its processes. 

There are several advantages to paging 
from files. First, it simplifies the imple¬ 
mentation of virtual memory by reusing 
the existing file mechanisms. Second, it 
provides flexibility not present when each 
machine uses a private partition for back¬ 
ing storage. Many workstations may store 
their backing files in the same file system 
domain; this uses disk space more effi¬ 
ciently than schemes based on statically 
allocated private partitions. The network 
file system also simplifies backing file allo¬ 
cation on local disks or remote servers and 
simplifies process migration by making all 
backing files accessible to all workstations. 

Backing files also have interesting per¬ 
formance consequences. In Sprite, remote 
backing files are cached in the main mem¬ 


ories of servers, just like all other files. Our 
initial measurements show that a client can 
read random pages from a file in the 
server’s cache faster than from a local 
disk, which means that a server with a large 
cache may provide better paging perfor¬ 
mance than a local disk. We think that 
CPU and network speeds are likely to 
increase at a much faster rate than disk 
speeds over the next few years, which will 
make remote paging to and from a server’s 
cache even more attractive in the future. 

Sticky segments. When a program starts 
execution, the pages in its code and data 
segments are loaded on-demand from the 
program’s object file when page faults 
occur. To reduce this cost for frequently 
invoked programs. Sprite keeps a pro¬ 
gram’s code pages in memory even after 
the program exits. The pages remain in 
memory until they are replaced using the 
normal clock mechanism. We call this 
mechanism sticky segments. If the same 
object file is reinvoked, then the new pro¬ 
cess can be started more quickly by reus¬ 
ing the sticky segment. If the object file is 
modified between executions, then the 
sticky segment will be discarded on the 
next execution. Data and stack segments 
are modified during execution, so they 
cannot be retained after the process com¬ 
pletes. 

Double caching. Double caching (cach¬ 
ing the same file block in two different 
memory locations) is a potential issue 
because the virtual memory system is a 
user of the file system. A naive implemen¬ 
tation might cause pages being read from 
backing files to end up in both the file 
cache and the virtual memory page pool; 
pages being eliminated from the virtual 
memory page pool might simply get 
moved to the file cache, where they would 
have to age again before being sent to the 
server. To avoid these inefficiencies, the 
virtual memory system bypasses the local 
file cache when reading and writing back¬ 
ing files. A similar problem occurs when 
demand-loading code from its executable 
file. In this case, the pages may already be 
in the file cache (for example, because the 
program was just-recompiled). If so, the 
page is copied to the virtual memory page 
pool and the block in the file cache is given 
an infinite age so that it will be replaced 
before anything else in memory. The sticky 
segment mechanism will cache the page in 
the virtual memory system, so it is not 
necessary to keep it in the file cache as well. 
For the portions of object files cor¬ 


responding to data pages, Sprite permits 
double caching to provide faster program 
start-up (the dirty data pages are discarded 
on program exit, but clean ones can be 
quickly reloaded from the file cache). 

Although the virtual memory system 
bypasses its local file cache when reading 
and writing backing files, the backing files 
will be cached on servers. This makes 
servers’ memories into an extended main 
memory for their clients. Servers do not 
cache backing files for their own 
processes, since this would constitute dou¬ 
ble caching; they only cache backing files 
for their clients. 

Virtual memory-file system negotiation. 

The virtual memory system and file system 
have conflicting needs for physical mem¬ 
ory. File system performance is best when 
the file cache is as large as possible, while 
virtual memory performance will be best 
when the file cache is as small as possible 
so that most of the physical memory may 
be used for virtual memory. To get the best 
overall performance, Sprite allows the file 
cache on each workstation to grow and 
shrink in response to changing demands 
on the machine’s virtual memory and file 
system. This is accomplished by having the 
two modules negotiate over physical mem¬ 
ory usage. The result is that small I/O¬ 
intensive programs, like compilers, may 
use almost all of the memory for a file 
cache, while large CPU-bound programs 
may use almost all of the memory for their 
virtual address spaces. 

The file system and the virtual memory 
system manage separate pools of physical 
memory pages. Each module keeps an 
approximate time-of-last-access for each 
page (using different techniques in each 
module). Whenever either module needs 
additional memory (because of a page 
fault or a miss in the file cache), it com¬ 
pares the age of its oldest page with the age 
of the oldest page from the other module, 
replacing whichever is older. This allows 
memory to flow back and forth between 
the virtual memory page pool and the file 
cache, depending on the needs of the cur¬ 
rent applications. 

We also considered more centralized 
approaches to trading off physical mem¬ 
ory between the virtual memory page pool 
and the file cache. One possibility would 
be to access all information through the 
virtual memory system. To access a file, it 
would first be mapped into a process’ vir¬ 
tual address space and then read or writ¬ 
ten just like virtual memory, as in Apollo’s 
Aegis system 5 or Mach. 13 This approach 
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Table 2. The time required to migrate a process on Sun-3/75 workstations.* 


Action 

Cost or speed 

Migrate smallest possible process 

190 msec 

Flush dirty pages 

585 Kbytes/sec 

Demand-load pages 

545 Kbytes/sec 

Transfer info for open files 

14 msec/file 

Flush file cache 

585 Kbytes/sec 


*The total time depends on how many dirty pages the process has (these must be flushed to 
the server during migration), how large its address space is (pages must be loaded on-demand 
on the process’ new host), how many open files it has, and how many dirty blocks for those 
files are cached locally (they must be flushed). “Smallest possible process” refers to a process 
with no open files and one page each of code, data, and stack. 


Table 3. Costs and benefits of process migration, measured by running several 
compilations concurrently.* 


Program 

Execution time 

Local Migrated 

Improvement 

One compilation 

15.5 sec 

15.9 sec 

-3% 

Two compilations 

30 sec 

17 sec 

43% 

Three compilations 

45 sec 

18 sec 

60% 

Four compilations 

60 sec 

20 sec 

67% 


*In the “local” column, all the compilations were run concurrently on a single machine. In 
the “migrated” column, one compilation was run locally and each of the others was migrated 
to a different workstation (except for the “one compilation” row, where the single compila¬ 
tion was migrated). 


would eliminate the file cache entirely; the 
standard page replacement mechanisms 
would automatically balance physical 
memory use between file and program 
information. 

We rejected the mapped-file approach 
for several reasons, the most important 
one being that it would have forced us to 
use a more complicated cache consistency 
scheme. Since a mapped-file approach 
requires a file’s pages to be cached in a 
workstation’s memory before they can be 
accessed, we would not have been able to 
implement cache consistency by refusing 
to cache shared files. A second reason for 
rejecting the mapped-file approach is that 
we wished to retain the Unix notion that 
I/O devices and files are accessed in 
exactly the same fashion; a mapped-file 
framework, with the assumed ability to 
access bytes in random order, does not 
seem natural for device I/O, which is most 
often sequential. 


Process migration 

Sprite’s implementation of process 
migration differs from other implementa¬ 
tions, such as those in the V System, 6 
Accent, 7 or Locus, 2 in two major ways. 
The first difference is the way in which a 
process’ virtual memory is transferred 
between machines, and the second differ¬ 
ence is the way migration is made transpar¬ 
ent to the migrated process. 

The simplest approach to process migra- 

• “freeze” the process (prevent it from 
executing any more); 

• transfer its state to the new machine, 
including registers and execution 
state, virtual memory, and file access; 

• “unfreeze” the process on its new 
machine so that it can continue 
executing. 


The virtual memory transfer is the dom¬ 
inant cost in migration, so various tech¬ 
niques have been applied to reduce it. For 
example, V uses precopying, where the 
process continues executing while its mem¬ 
ory is transferred. The process is then fro¬ 
zen, and any pages that have been 
modified are recopied. Accent uses a 
“lazy” approach in which the virtual 
memory image is left on the old machine 
and transferred to the new machine one 
page at a time when page faults occur. 
Locus checks for a read-only code segment 
and reopens it on the new machine, rather 
than copying it from the old machine; this 
allows the process to share a preexisting 
copy of the code on the new machine, if 
there is one. 

In Sprite, backing files simplify the 
transfer of the virtual memory image. The 
old machine simply pages out the process’ 
dirty pages and transfers information 
about the backing files to the target 
machine. If the code segment already 
exists on the new machine, the migrating 
process shares it, as in Locus. Pages get 
reloaded in the process’ new machine on 
demand, using the standard virtual mem¬ 
ory mechanisms. Thus, the process need 
only be frozen long enough to write out its 
dirty pages. The Sprite approach requires 
processes to be frozen longer than with 
either V or Accent, but it requires less data 
copying than V and does not require page 
fault servicing by the old machine after 
unfreezing on the new machine. 

The second, and more important, issue 
in process migration is achieving transpar¬ 
ent remote execution. A migrated process 
must produce the same results it would 
produce if it were not migrated, and spe¬ 
cial coding must not be required for a 
process to be migratable. For message- 
based systems like V and Accent, trans¬ 
parency is achieved by redirecting the 
process’ message traffic to its new home. 
Since processes communicate with the rest 
of the world only by sending and receiving 
messages, this is sufficient to guarantee 
transparency. In contrast, Sprite processes 
communicate with the rest of the world by 
invoking kernel calls. Kernel calls are nor¬ 
mally executed on the invoking machine 
(unless they make RPCs to other kernels), 
and some kernel calls will produce differ¬ 
ent results on different machines. For 
example, Sprite kernels maintain shared 
environment variables; Proc_GetEnviron 
may return different results on different 
machines. 

Sprite achieves transparency in a fash¬ 
ion similar to Locus by assigning each 
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process a home node. A process’ home 
node is the machine on which the process 
was created, unless the process was created 
by a migrated process; in this case, the 
process’ home node is the same as the 
home node of its parent. Whenever a pro¬ 
cess invokes a kernel call whose results are 
machine-dependent, the kernel call is for¬ 
warded to the process’ home node (using 
the RPC mechanism) and executed there. 
This guarantees that the process produces 
the same results as if it were executing at 
home. To the outside world, the process 
still appears to be executing at home. Its 
process identifier does not change; it will 
appear in a process listing on the home 
node; and it can be debugged and termi¬ 
nated in the same way as other processes 
on the home node. 

For each kernel call, we thus had two 
choices: either transfer all the state 
associated with the call at migration time 
so that the call can be executed remotely, 
or forward home all invocations of the call 
made by migrated processes. For calls that 
are invoked frequently, such as all the file 
system calls, we chose the first course (this 
was particularly simple for files, since the 
cache consistency mechanism already 
takes care of moving the file’s data 
between caches). For infrequently invoked 
calls, or those whose state is difficult or 
impossible to transfer (for example, calls 
that deal with the home node’s process 
table), we chose the forwarding approach. 

Table 2 gives some preliminary meas¬ 
urements of process migration costs. If a 
process is migrated when it starts execution 
(before it has generated many dirty pages), 
the migration requires only a few hundred 
milliseconds on Sun-3/75 workstations. 
We expect this to be the most common sce¬ 
nario. The other major use of migration 
will be to evict migrated processes from a 
workstation whose user has just returned. 
In this case, the major factor will be the 
number of dirty pages. Even in the worst 
case (all memory dirty), all processes can 
be evicted from an eight-megabyte work¬ 
station in about 15 to 20 seconds. Table 3 
shows that remote execution costs are 
acceptable (less than five percent penalty 
over executing at home for a compilation 
benchmark) and that migration may allow 
much more rapid completion of a collec¬ 
tion of jobs. (See Douglis and 
Ousterhout 14 for more information on 
process migration in Sprite.) 

A s of this writing, all features dis¬ 
cussed are operational—except 
for the code to choose a target 


for process migration and to evict 
migrated processes when a workstation’s 
user returns, which is currently under 
development. In addition. Sprite supports 
the Internet protocol family (IP/TCP) for 
communication with other systems, and 
Sun NFS protocol support is planned. The 
Sprite kernel contains approximately 
100,000 lines of code, about half of which 
are comments. All but a few hundred lines 
of code are in C; the remainder are writ¬ 
ten in assembler. Sprite currently runs on 
Sun-2 and Sun-3 workstations. Recently, 
we began using it for all of our everyday 
computing, including maintaining Sprite. 
We plan to port Sprite to the SPUR multi¬ 
processor as prototypes become available 
later in 1988. We hope that Sprite will be 
portable enough to run on a variety of 
workstation platforms, and that it will be 
attractive enough for people outside the 
Sprite group to want to use it for their 
everyday computing. 

In conclusion, we hope that Sprite will 
provide three overall features: sharing, 
flexibility, and performance. Users want 
sharing so that they can work coopera¬ 
tively and use hardware resources fully. 
Sprite provides sharing at several levels: 
tightly coupled processes on the same 
workstation may share memory; processes 
everywhere may share files; and users may 
share processing power using the process 
migration mechanism. System administra¬ 
tors want flexibility so that the system can 
evolve gracefully. Sprite provides flexibil¬ 
ity in the form of prefix tables, which allow 
user-transparent reconfiguration of the 
file system, and in the form of backing 
files, which allow workstations to share 
backing storage. Finally, everyone wants 
performance. Sprite provides high perfor¬ 
mance by using a special-purpose RPC 
protocol for communication between ker¬ 
nels and by using physical memory as a 
flexible cache for both programs and 
files. □ 
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Sequoia: A Fault-Tolerant 
Tightly Coupled 
Multiprocessor for 
Transaction Processing 

Philip A. Bernstein* 

Sequoia Systems 


T ransaction processing applica¬ 
tions require computers that have 
high performance, are extremely 
reliable, and are modularly expandable. 
To meet these goals, computer manufac¬ 
turers have developed products that use 
fault-tolerant multiprocessor architec¬ 
tures. The two main styles of multiproces¬ 
sor architectures are: loosely coupled, 
where each processor has private memory 
and I/O resources and can communicate 
with other processors by exchanging mes¬ 
sages; and tightly coupled, where each 
processor has direct access to all memory 
and I/O resources and can communicate 
with other processors through the shared 
memory. Tandem, 1 Stratus, 2 and 
Auragen 3 use loosely coupled architec¬ 
tures. ** Encore 4 and Sequent 5 use tightly 
coupled architectures without special 
fault-tolerance capability. Intermediate 
architectures with limited sharing are also 
used, as in Digital’s VAXcluster architec- 


This paper was produced before the author joined 
Digital Equipment Corp. The views expressed are 
exclusively those of the author and do not reflect the 
opinions or future product plans of Digital. 

*'Stratus tightly couples up to six processors in each 
processor module. The modules are then loosely 
coupled. 



The Sequoia 
computer’s 
multiprocessor 
architecture attains a 
high level of 
fault-tolerance using 
hardware fault 
detection and 
operating system 
fault recovery. 


ture, 6 where processors share I/O but not 
memory. 

Fault isolation is the main benefit of 
loosely coupled multiprocessors. Each 
processor fails independently without cor¬ 
rupting resources owned by other proces¬ 
sors. In contrast, a failure in a tightly 
coupled multiprocessor can potentially 

IEEE 


corrupt shared memory, causing all 
processors to fail. 

Automatic sharing and balancing of 
load is the main benefit of tightly coupled 
multiprocessors. All processors share a 
single queue of ready processes, so all 
processors do useful work as long as work 
is available. A single pool of shared mem¬ 
ory can be dynamically allocated to buffer 
I/O from whichever devices need it most. 
In addition, only one copy of each soft¬ 
ware module needs to be kept in main 
memory, which is shared by all processors. 
In contrast, in a loosely coupled multipro¬ 
cessor, processes must be explicitly 
assigned to each processor, allowing for 
potential load imbalances. Such an 
imbalance can be repaired by moving a 
process to a different processor; however, 
moving of such processes between proces¬ 
sors is expensive. Memory local to a 
processor can only be used to buffer I/O 
from devices connected to that processor. 
And, each processor must allocate mem¬ 
ory to common systems software, such as 
the operating system, database system, 
and communications system. 

The Sequoia computer is a tightly cou¬ 
pled multiprocessor, and thus attains the 
performance advantages of this style of 
architecture. It avoids most of the fault- 
tolerance disadvantages of tight coupling 
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Figure 1. Sequoia hardware architecture. 


by using a new fault-tolerance design. The 
Sequoia architecture is similar to other 
multimicroprocessor architectures, such as 
those of Encore and Sequent, in that it 
gives dozens of microprocessors shared 
access to a large main memory. It resem¬ 
bles the Stratus architecture 2 in its exten¬ 
sive use of hardware fault-detection 
techniques. It resembles Stratus and Aura- 
gen in its ability to quickly recover all 
processes after a single point failure, trans¬ 
parently to the user. However, Sequoia is 
unique in its combination of a large-scale 
tightly coupled architecture with a hard¬ 
ware approach to fault tolerance. 

This article gives an overview of how the 
hardware architecture and operating sys¬ 
tem (OS) work together to provide a high 
degree of fault tolerance with good system 
performance. 

Hardware overview 

Hardware architecture. A Sequoia com¬ 
puter consists of processor elements (PEs), 
memory elements (MEs), and I/O ele¬ 
ments (IOEs) connected by a system bus 
(see Figure 1). 

Bus structure. The system bus consists 
of two 40-bit 10-megahertz buses that 


operate independently, for an aggregate 
throughput of 80 megabytes per second. 
The system bus (Figure 1) is composed of 
three types of segments: processor local 
segments that hold PEs, memory local seg¬ 
ments that hold MEs and IOEs, and global 
segments that connect processor and mem¬ 
ory local segments. (A small system con¬ 
sisting of just one bus segment can violate 
these configuration rules by mixing PEs, 
MEs, and IOEs on the same segment.) 
Each processor local segment holds up to 
eight elements and connects to a global 
segment through a master interface (MI). 
Each memory local segment also holds up 
to eight elements and connects to a global 
segment through a slave interface (SI). The 
MI arbitrates access to the buses; both the 
Mis and Sis are repeaters that electrically 
isolate each bus segment. Up to eight 
processor local segments and 16 memory 
local segments can be connected by global 
segments in a single system. Thus, a system 
can physically contain up to 64 PEs and 
128 MEs and IOEs (combined total), of 
which 96 can be IOEs. 

Processor. Each PE contains dual 
20-MHz MC68020 microprocessors from 
Motorola that operate in lock-step, with 
comparators that test for identical opera¬ 
tion on each clock cycle. Each PE has a 


I local clock, so a failure of that clock only 
disables the PE on which it resides. Each 
PE also has 2048 128-byte blocks of four¬ 
way associative cache memory with a 40 
nanosecond access time, and a memory 
management unit that maps 32-bit virtual 
addresses into 32-bit physical addresses. 

The cache is non-write-through, mean¬ 
ing that updates written to cache by the 
microprocessor are not immediately writ¬ 
ten to main memory. Instead, the OS must 
explicitly ask the PE to flush the contents 
of its dirty (that is, updated) data blocks 
to ME memory. The OS may chose to 
flush the cache to refresh the main mem¬ 
ory copy of data recently updated in cache. 
Or, it may be forced to flush the cache due 
to a cache overflow. This occurs when 
newly referenced data must be brought 
into the cache but, because all cache blocks 
that can hold the data are dirty, there is no 
place to put it. In this case, dirty data 
blocks must be written to main memory to 
make room for the new data. 

Special-purpose hardware in the PE 
flushes all the dirty cache blocks with a sin¬ 
gle instruction. The flush takes approxi¬ 
mately four microseconds times the 
number of dirty blocks. Half of the cache 
is a read-only instruction cache, and half 
is a writable data cache. The maximum 
flush time for the 1024 blocks of data 
cache is four milliseconds. 

Controlling bus traffic is an important 
problem in building tightly coupled com¬ 
puters to ensure that processors rarely wait 
to access the bus. Most bus traffic is gener¬ 
ated by PEs accessing MEs. The cache is 
critical to controlling this traffic. The large 
associative cache produces a very high hit 
ratio, more than 99 percent. (This hit ratio' 
was derived by measuring bus traffic and 
calculating the hit ratio required to pro¬ 
duce that traffic. It is consistent with pub¬ 
lished data. 7 ) 

The non-write-through nature of the 
cache allows PEs to perform multiple 
writes to a cache block before flushing that 
block back to its ME. In addition, the unit 
of transfer between cache and MEs is 
rather large, 128 bytes, which reduces pro¬ 
tocol overhead per byte transferred. These 
features help reduce bus traffic, making it 
possible to connect a large number of PEs 
without overloading the bus. 

Main memory. Each ME contains either 
eight or 16 megabytes of random-access 
memory, is four-way interleaved, and has 
an access time of 100 nanoseconds. It also 
contains 1024 test-and-set locks, which are 
used by the OS to ensure mutually exclu- 
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sive access to shared memory. The opera¬ 
tion test-and-set(A r , Y) performs the 
following sequence atomically: (1) if X= 
0 (that is, the lock is not set), then set the 
lock by storing into X the value Y( Y > 0); 
and (2) return the number stored in X 
before the test-and-set was executed. 

I/O processor. Each IOE (see Figure 2) 
consists of two sections: a bus adapter 
(BA) that connects to a memory local seg¬ 
ment, and a multibus adapter (MA) that 
connects to an Intel Multibus and func¬ 
tions as the I/O bus. 

Each BA contains four 4-kilobyte 
buffers plus synchronization and direct 
memory access logic for passing data 
between its associated MA and all of the 
MEs (not just those on its own memory 
local segment). The BA and MA are inter¬ 
connected by a dedicated bus up to 1000 
feet long, thereby allowing the peripheral 
cabinet to reside far from the main cabi¬ 
net. Its bandwidth is up to five megabytes 
per second, depending on length. Each 
MA contains a pair of self-checking 
10-MHz MC68010 microprocessors, two 
megabytes of memory used for data 
buffering, and a 256-kilobyte programma¬ 
ble read-only memory for program stor¬ 
age. Each Multibus can support up to 12 
I/O controllers for tape, disk, and com¬ 
munications. 

Fault tolerance. Fault detection 
mechanisms fully cover each type of ele¬ 
ment and the system bus. Three types of 
mechanism are used: error-detecting 
codes, comparison of duplicated opera¬ 
tions, and protocol monitoring. 

Coding. All data are protected by error¬ 
detecting codes, both while stored in mem¬ 
ory (for example, in the PE’s cache, BA’s 
buffers, and MA’s local memory) and 
while being transferred over buses. Byte 
parity is used except in MEs, which use an 
extended Hamming SEC-DEC code that 
covers failures of the encoder/decoder 
itself. 

The hardware implementing all data 
storage and transfer paths is partitioned so 
that no two bits of the same byte, includ¬ 
ing the parity bit, have any common com¬ 
ponents. Consequently, single-component 
failures can only produce a single error in 
any byte and all such errors are detectable. 
In all cases, half of each four-byte address 
or data word is protected by odd parity 
and half by even parity. Thus, faults leav¬ 
ing data paths in their quiescent state, typi¬ 
cally all zeros or all ones, produce 


Figure 2. I/O element. 


detectable error patterns. No single¬ 
component failure, even in the 
encoder/decoder itself, can produce an 
undetectable data error. The attention 
paid to these relatively uncommon but not 
negligibly rare failure modes exemplifies 
the care taken throughout the system for 
error detection. 

Comparison of duplicated operations. 
Coding is usually the least expensive of 
error detection mechanisms. However, a 
coder-decoder that supports coding for 
some types of complex logic networks can 
be more expensive than the network itself. 
Microprocessors, address generation 
logic, and cache management functions 
are of this type. For these components, it 
is less expensive to use hardware duplica¬ 
tion and comparison to detect failures. 
Each component (a single chip or more 
complex circuit) is duplicated and augmen¬ 
ted with a comparator. This comparator 
is duplicated and tested in the background 
on a bit-by-bit basis. All operations are 
performed independently on both compo¬ 
nents, with each component comparing its 
own results to those produced by the other. 

Protocol monitors. The combination of 
coding and comparison of duplicated 
operations will not detect all hardware 
faults. For example, if a PE addresses an 
ME and the ME cannot respond (possibly 
due to an internally detected fault), then 
either the PE or the bus connecting the PE 
and ME could be permanently disabled 
waiting for a response that never comes. 
Protocol monitors prevent such problems 
by detecting violations in the sequence and 
timing of inter-element communication. 


Together, the fault detection techniques 
discussed above provide immediate detec¬ 
tion of all single errors resulting from 
hardware faults. The only possible fault 
that could remain undetected is a fault in 
the detection circuitry itself. For this rea¬ 
son, the OS periodically tests each hard¬ 
ware monitor to verify that it can detect 
and report all faults it was designed to test. 
A fault detection monitor might fail 
between OS tests, but this is not a problem. 
If a monitor fails by reporting a nonexis¬ 
tent fault, then the element containing the 
fault is diagnosed as failed. (It did fail; its 
fault-detection circuitry malfunctioned.) 

If a monitor becomes incapable of 
reporting certain faults, the danger arises 
that an undetected second fault will actu¬ 
ally occur before this monitor failure is 
observed by an OS test. Testing the fault 
monitors daily is sufficient to reduce the 
probability of such an event to exceedingly 
small levels—approximately 1/(2 x 365 x 
M) where Mis the mean time between fail¬ 
ure of the monitored component. For 
similar reasons, each ME block is period¬ 
ically read and restored to prevent the 
accumulation of undetected single-bit 
errors in infrequently accessed data. 

Upon detecting a fault, the element 
involved instantaneously disables its exter¬ 
nal outputs, thereby preventing the fault 
from affecting other elements. The OS is 
notified on the next attempt (by any soft¬ 
ware or hardware module) to access the 
faulted element. The OS takes over by 
initiating fault recovery, a process 
described later in this article. 

Operating system architecture. To real¬ 
ize the advantages of a standard OS while 
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meeting the high performance require¬ 
ments of transaction processing, Sequoia 
has implemented its own proprietary ker¬ 
nel that offers a superset of the function¬ 
ality of Unix System V. 8 

Sequoia’s kernel provides the user with 
fault tolerance at the level of fail-safe 
processes and files. As long as the system 
has at least two of each element, each proc¬ 
ess is resilient to any single-point hardware 
failure. For example, if a PE fails while 
executing a process, this process is trans¬ 
parently reassigned to another processor 
and continues executing, with no impact 
on the application. If an ME malfunc¬ 
tions, any data or code stored in that ME 
is recovered from elsewhere in the system. 
Files are made fault tolerant by using mir¬ 
rored disks connected to different IOEs. 
In most of these cases, some performance 
degradation can result from the failure. 
However, the larger the configuration, the 
smaller the marginal loss in power that 
results from the failure of any single 
element. 

Given Sequoia’s tightly coupled archi¬ 
tecture, there is only one copy of the ker¬ 
nel in ME memory, and that copy is 
executed on demand by any PE. That is, 
when a process executing on a PE per¬ 
forms a system call, that system call 
invokes the kernel on that same PE. Since 
the kernel may be executing on many PEs 
at a time, each PE uses test-and-set locks 
and controls its cache flushing to syn¬ 
chronize access to shared kernel data. This 
combination of locking and flushing lies 
at the heart of the Sequoia computer’s 
approaches to tight coupling and fault 
tolerance. 

The multiprocessor 

synchronization 

problem 

The kernel requires access to many data 
structures: process descriptors, page 
tables, file descriptors, etc. Each of these 
data structures may be accessed by more 
than one PE at a time, resulting in a race 
condition. In the example in Figure 3, the 
numbers to the left of the program state¬ 
ments indicate the order of operations in 
real time. 

In Figure 3a, two processors added one 
to x, but one of the updates was lost. The 
kernel must consider access to shared data, 
such as x, to be a critical section and must 
use a mutual exclusion protocol to prevent 
race conditions. We describe Sequoia’s 


mutual exclusion protocol through a 
sequence of examples that illustrate the 
problems the protocol is designed to solve. 

Each data structure on which the kernel 
seeks to provide mutual exclusion is allo¬ 
cated a test-and-set lock. (We will consider 
the allocation strategy later in this article.) 
Each PE obtains the lock for a data struc¬ 
ture before entering a critical section that 
accesses the data structure and releases the 
lock upon leaving the critical section. 
However, if this were the complete pro¬ 
tocol, it would not completely solve the 
problem, because of the non-write- 
through cache. 

For example, if we use lock a to guard 
access to data structure x, the preceding 
execution could follow the incorrect path 
in Figure 3b. After releasing the lock on a 
in step 4, PE #1 still has a copy of x in its 
cache and has not yet flushed it to ME 
memory. Therefore, when PE #2 sets the 
lock on a, it incorrectly reads the old value 
of x from ME memory (that is, the value 
of x before PE #1 updated it). To avoid 
this problem, each PE should flush all of 
its dirty cache before releasing a lock, 
thereby ensuring that the next PE to obtain 
the lock will receive the most up-to-date 
value of the shared data covered by the 
lock. 

One final cache problem remains, due 
to the nature of the PE hardware. When 
a PE flushes its cache, the data that sits in 
that cache remains valid for future 
accesses. For example, in Figure 3c, the 
value of x read by PE #1 in step 12 would 
be the value left in its cache after step 4, 
because x’s area of cache is still valid. 

To force the PE to ignore the contents 
of such stale cache blocks, it must invali¬ 
date these blocks. After the blocks are 
invalidated, the cache management hard¬ 
ware will go to ME memory to service any 
memory access requests to these blocks. 
To invalidate stale cache blocks, the PE 
uses the following mutual exclusion 
protocol: 

Get test-and-set lock 
Invalidate non-dirty cache 
*** Critical Section Code *** 

Flush (dirty) cache 
Release test-and-set lock 
In this protocol, a PE only invalidates 
its non-dirty cache blocks after it obtains 
a lock /. Every stale cache block must be 
non-dirty, because it was flushed (and 
thereby made clean) when the lock on the 
corresponding memory area was last 
released. (Releasing the lock without 
invalidating the block is what made the 


block stale.) Therefore, invalidating non- 
dirty blocks forces the PE to read a fresh 
copy of the memory area covered by / into 
its cache. And, since it is not invalidating 
any dirty cache blocks, the PE will not lose 
any updates to other areas of cache. This 
invalidation is implemented as a single 
hardware instruction. 

Notice that it would be incorrect for a 
PE to invalidate its writable cache after 
obtaining a lock. For example, suppose a 
PE concurrently locks two different mem¬ 
ory areas, x and y. Suppose the PE first 
locks x. If it then locks y, the cache would 
be invalidated, thereby losing any updates 
to x (or any other updated areas of cache, 
for that matter). 

This mutual exclusion protocol is 
embedded in a low layer of the kernel that 
supports the abstraction of shared kernel 
memory. The command to create an area 
of shared memory allocates ME memory 
for the area and a lock. The mutual exclu¬ 
sion protocol is abstracted by commands 
to request and release access to the mem¬ 
ory area. 

Deadlocks are avoided by the conven¬ 
tional approach of totally ordering all 
resources on which locks can be obtained 
and requiring that those resources be 
locked according to that total order. 

Lock Contention. When a PE requests 
an unavailable lock, it spins in a loop, peri¬ 
odically testing whether the lock has 
become available. Lock contention may 
cause PEs to spend too much time in this 
loop. If lock contention is especially high, 
it may cause the addition of PEs to pro¬ 
duce no net gain in effective processing 
power. Lock contention must be 
minimized to maximize the number of PEs 
that can be usefully connected to the sys¬ 
tem. Lock contention depends on the 
length of time PEs hold each lock (the 
locked time) and the rate at which they 
obtain each lock (the locking rate). 

PEs only hold locks while running ker¬ 
nel code. This inherently limits locked time 
by completely decoupling it from the exe¬ 
cution time of user programs (though not 
from the number of kernel calls). To limit 
locked time further, the kernel never holds 
a lock* across a context switch. This 
ensures it never turns its attention away 
from a request that sets a lock, with no 


"This is only true for OS locks on shared main mem¬ 
ory. Database locks are held for longer periods and are 
not implemented as test-and-set hardware locks. 
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constraint on how quickly it returns to tha 
request. For example, the kernel release: 
all locks immediately after initiating a syn¬ 
chronous I/O request, because this results 
in a context switch. With these restrictions, 
reducing locked time and locking rate is 
then principally a matter of careful design 
and tuning. 

Partitioning lockable resources. One 
important method of reducing lock con¬ 
tention is randomly partitioning lockable 
resources into smaller granularity units, 
with a separate lock for each partition. 
With this strategy, two PEs are less likely 
to contend for a lock because they are less 
likely to require access to the same parti¬ 
tion. A similar approach is described in 
Bach. 9 

The partitioning must be randomized. 
Otherwise, a partition may be more likely 
to experience especially heavy access due 
to a skewed usage pattern, and thereby 
defeat the goal of partitioning. For exam¬ 
ple, if file descriptors are partitioned by the 
disk drive that stores the files, then an 
application that heavily accesses files on 
one disk will access the corresponding file 
descriptor partition, causing heavy lock 
contention. A random partitioning of the 
resource (in this case, file descriptors) 
would be less likely to see the heavy access, 
since there is no natural correlation 
between access patterns on the resource 
and the partitioning of the resource. 

Each shared resource is a table. It is ran¬ 
domly partitioned into smaller tables by 
assigning rows to different subtables, 
based on a hashing function using the 
table’s key (for example, process-id or file- 
id). Each subtable is assigned its own lock, 
thereby decreasing the locking rate on each 
lock and hence reducing lock contention. 

All kernel tables for which lock conten¬ 
tion is an issue are partitionable in this 
way. The partitioning occurs dynamically 
in response to an operator request that 
names the lock and the number of parti¬ 
tions desired. To help the operator decide 
when to repartition, a monitor provides 
the fraction of time a processor is waiting, 
on the average, for each lock. This activity 
could easily be automated by establishing 
a threshold for waiting time, above which 
repartitioning should be automatically 
triggered. 

Preliminary experiments indicate a wide 
range of contention rates for different 
resources. For some resources, the ratio of 
PEs to partitions must be as low as 1:1 to 
avoid significant locking delay. Some 
resources are not partitioned because their 
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Figure 3. Solving the mutual exclusion problem: (a) a race condition; (b) an incor¬ 
rect solution using locks; and (c) an incorrect solution using locks and flushes. 


lock contention is very low. Said differ¬ 
ently, the ratio of PEs to partitions needed 
to avoid contention for these resources is 
greater than 64:1, which is effectively 
infinite. 

By hashing a resource’s key, the kernel 
can easily determine which partition to 
lock to access that resource, so the parti¬ 
tioning has little effect on software com¬ 
plexity. However, partitioning does add 
some complexity when resources in differ¬ 
ent partitions must be grouped together. 
For example, process family trees and 
waiting queues each require linking 


together processes in different partitions 
of the process table. Accessing these 
groups may require locking more than one 
partition, thereby defeating the reason for 
partitioning and creating a potential dead¬ 
lock problem that requires careful algo¬ 
rithm design. If such accesses are frequent, 
then the lock granularity is inappropriate 
and a different partitioning should be 
selected. Only a modest amount of design 
effort was required to find an appropriate 
partitioning of kernel tables. 

All processors must have access to all 
partitions. Partitioning does not restrict 
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Without Optimization 

lock (x) 

operation (1 ms) 
flush cache (.3 ms) 
phys_unlock (x) 
operation (.1 ms) 
lock (x) 

operation (1 ms) 
flush cache (.3 ms) 
phys_unlock (x) 


With Optimization 

lock (x) 

operation (1 ms) 
log_unlock (x) 
operation (.1 ms) 
lock (x) 

operation (1 ms) 
log_unlock(x) 
flush cache (.3 ms) 
phys_unlock (x) 


Figure 4. Holding locks longer can reduce locked time. 


which resources are accessible to which 
processors. If it did, the benefit of auto¬ 
matic load balancing provided by the 
tightly coupled architecture would be 
diminished. 

Bus contention. Another performance 
issue connected to this locking protocol is 
the frequency of cache flushing. Although 
a typical system call acquires one lock, 
some require more. If releasing each lock 
were to cause a cache flush, then the cache 
flushes would often be too costly. They 
would reduce PE utilization (the processor 
is stopped while a flush is in progress) and 
increase bus usage and, hence, bus con¬ 
tention. 

To avoid a separate flush on each lock 
release, the physical releasing of locks is 
postponed until the completion of the sys¬ 
tem call, cache overflow, or context switch 
that caused the flush (just before return¬ 
ing to user state). This is done by distin¬ 
guishing between locks that have been 
logically released because the kernel con¬ 
text no longer needs exclusive access to the 
corresponding resource and those that 
have been physically released by actually 
releasing the hardware lock. When a lock 
is logically released, the layer that manages 
locks notes that fact but does not physi¬ 
cally release the lock at the time. After a 
PE flushes the cache, it physically releases 
all locks that were logically released since 
the last flush. 

This optimization may increase locked 
time because locks are physically held 
longer than they are logically needed. (Any 
extra contention that this creates is auto¬ 
matically controlled by dynamic partition¬ 


ing.) However, it can also reduce locked 
time. For example, consider the locking 
sequence in Figure 4. Lock releases are 
labeled as physical (phys_unlock) or logi¬ 
cal (log_unlock). Without optimization, 
the lock on x is held through two cache 
flushes, for a total of 2.6 milliseconds. 
With the optimization, it is only held 
through one flush, for a total of 2.4 mil¬ 
liseconds. 

A study of bus traffic was performed by 
measuring the bus utilization during exe¬ 
cutions of a relational database system, 
Ingres. Each processor used approxi¬ 
mately four percent of the bandwidth of 
one bus. Since each PE generates bus 
requests virtually independently of the 
behavior of other PEs, bus utilization 
should be linear in the number of proces¬ 
sors. This has been empirically validated 
for up to 12 processors. This suggests that 
20 to 25 PEs could operate productively on 
one bus, though a system that large has not 
yet been built. (The largest has 12 PEs.) 
Based on experience with smaller config¬ 
urations, we believe that lock contention 
with 25 PEs will degrade overall PE per¬ 
formance by about one to five percent, 
depending on the application. 


Kernel support for fault 
recovery 

At any time, the system may experience 
a hardware fault in a PE, ME, IOE, bus, 
controller, or peripheral device. No mat¬ 
ter when a fault occurs, it must be possi¬ 
ble to recover the process that experienced 


the fault without losing its process state or 
losing or duplicating * I/O operations. To 
ensure this, the kernel guarantees that the 
state of every process in main memory is 
always internally consistent; that the state 
of kernel data structures is consistent with 
main memory process states; and that no 
I/O operations are lost or repeated. 

Processor failures. Suppose a PE faults 
(and therefore disconnects itself from the 
bus) at a time when it is not flushing its 
cache. The ME memory image of the proc¬ 
ess that it was executing at the time of the 
fault is the state of that process at the time 
of the PE’s last cache flush. To ensure that 
the memory image is always executable, all 
dirty blocks are flushed and a copy of the 
PE’s (that is, MC68020’s) internal registers 
is saved and flushed on every cache flush. 
Therefore, the state of the process is con¬ 
sistent. Thus, if the fault happens while the 
PE is not flushing its cache, the kernel 
(running on another PE) need only iden¬ 
tify the process assigned to the faulted PE 
and return it to the ready queue. 

What if the PE was flushing its cache at 
the time it faulted? A cache flush is not 
atomic relative to PE faults. So a fault dur¬ 
ing a cache flush may leave the memory 
image of a process in an inconsistent state, 
with some of memory containing the 
image of the process before the flush and 
some of it containing its image after the 
flush. To avoid this problem, writable 
pages are shadowed. That is, each writa¬ 
ble page is stored in two different MEs. 
Program pages and read-only data pages 
are not shadowed, because they are never 
written and therefore cannot be corrupted 
by a cache flush. 

When a PE flushes its cache, it actually 
flushes twice. First, it flushes to the backup 
copy of its pages and, when that is com¬ 
plete, it flushes to the primary. The hand¬ 
shake between the two flushes ensures that 
either the primary or backup copy of the 
pages is a consistent image of the process 
and kernel memory states. If a PE faults 
during its backup flush, then the primary 
copy is a consistent image as of the previ¬ 
ous flush. If it faults during its primary 
flush, then the backup copy is a consistent 
image as of the current flush. In either 
case, the inconsistent copy can be 
refreshed by reading the consistent copy. 
After memory is successfully refreshed, 


♦Failures of certain types of peripherals (such as ter¬ 
minals) may require the duplication of an I/O opera¬ 
tion to ensure that the operation was completed. 
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the process can be returned to the ready 
queue. 

This approach requires that the PE per¬ 
forming recovery can tell whether the 
faulted PE was flushing at the time it 
faulted and, if so, which of the two flushes 
was in progress. For reasons discussed at 
the conclusion of this article, only one PE 
may flush its cache at a time. Two locks are 
allocated for this purpose. A PE must 
obtain the first lock before flushing its 
cache. Thus, the contents of this lock tell 
if a PE is flushing and, if so, the second 
lock is used to tell which flush is in prog¬ 
ress (the first or second). This serialization 
of cache flushes does not create meaning¬ 
ful lock contention. Contention for this 
lock merely masks bus contention that 
would exist if the flushes were not seri¬ 
alized. 

Main memory failures. Two MEs are 
paired as shadows under kernel control 
through ME registers. To store a page in 
shadowed memory, the page is stored at 
the same offset on both MEs of a 
shadowed pair of MEs. Shadowed MEs 
can also store nonshadowed pages by stor¬ 
ing different pages at the same offset of the 
two MEs. 

All writable data pages are shadowed on 
two MEs. All code and read-only data 
pages are backed up on disk. So, if an ME 
fails, every page in that ME exists else¬ 
where in the system. 

When an unshadowed ME fails, the 
page tables are updated to reflect the fact 
that the ME’s pages are no longer in main 
memory. The next access to such pages 
causes a page fault, which is handled in the 
normal manner. 

When a shadowed ME fails, the system 
recovers all of ME memory into an 
unshadowed state, all shadowed MEs 
become unshadowed, and all page tables 
are updated to reflect the new memory 
state. After recovery is complete, the ker¬ 
nel spawns a process that reshadows the 
system. 

Avoiding lost I/O. Each IOE has a 
queue in main memory containing pend¬ 
ing I/O operations to that IOE. To per¬ 
form an I/O, a PE constructs a description 
of the operation in its cache and then 
flushes that description to the appropriate 
queue. Once an I/O is successfully 
appended to that queue, it is guaranteed to 
be performed. An I/O is deleted from the 
queue only after the IOE acknowledges the 
I/O’s completion. 

Therefore, a PE successfully initiates an 


I/O operation by completing its flush. 
Suppose a PE fails during a flush that will 
initiate an I/O. After any such failure, the 
memory state is recovered either to the 
state before the PE’s last cache flush (if it 
failed during the backup flush) or to the 
new state (if it failed during the primary 
flush). In the former case, the I/O is not 
issued, because the flush was undone, and 
the process state reverts to a state before 
it issued the I/O. In the latter case, the I/O 
is issued, because the flush is completed, 
and the process state is just past the point 
that it issued the I/O. Therefore, the I/O 
is not lost and the process will not repeat it. 

After a fault, it is not always possible for 
the PEs to tell which I/O operations have 
actually been sent to the IOE, for example, 
if a PE fails while sending operations to an 
IOE. To avoid losing I/O, it is necessary 
to validate that the queue’s view of which 
I/O operations have been sent is consistent 
with the IOE’s view. Therefore, after a 
fault, each IOE is interrogated to deter¬ 
mine which of its queued I/O operations 
it has seen. The IOE maintains a list of all 
in-progress I/O operations for this 
purpose. 

I/O failures. Disk failures are handled 
using dual-ported mirrored disks on 
different IOEs. The kernel routes each 
write to both disks of a mirrored pair. It 
load balances reads by sending half to each 
disk, thereby doubling the read bandwidth 
of the mirrored disk. If a disk fails, the 
other disk picks up the full load. If a con¬ 
troller or IOE fails, then an attempt is 
made to use an alternate path to the device; 
if the attempt fails, the mirror is used. 
Disks are recovered on line. 

A communications line can be made 
more reliable by routing it through a 
switch to two controllers on different 
IOEs. If a controller fails, the kernel or 
application can switch the lines to other 
controllers. However, since a few mes¬ 
sages may be lost in the failed controller, 
software running the higher levels of the 
communications protocol usually must 
cope with the failure in a protocol-specific 
manner. Such failures are therefore not 
always transparent to software. Switching 
ports appears to the software as if each line 
on the controller experienced a transient 
line failure. Since lines fail much more fre¬ 
quently than controllers, many protocols 
cope with such failures anyway. 

A permanent failure of an IOE is treated 
as the failure of all of its controllers. A 
transient failure of an IOE causes the state 


of the IOE to be reloaded from ME 
memory. 

The recovery process 

PEs observe hardware faults in differ¬ 
ent ways. When an ME or IOE experiences 
a fault, it goes into an error state and will 
not respond to normal requests until the 
error is cleared. An attempt by a PE to 
access such a module results in a watchdog 
timer error. 

PE faults are detected by polling. Each 
PE has a 128-byte status block in ME 
memory that it updates every 100 millise¬ 
conds. A designated PE polls these status 
blocks periodically to determine if any PE 
is no longer functioning. Using the same 
method, all other PEs check that the desig¬ 
nated PE is functioning. If any PE detects 
a moribund PE, it assumes the PE has 
faulted and puts the system into fault 
recovery. 

When some PE observes a hardware 
fault, it immediately notifies all other PEs 
using a high-priority interrupt. (If fault 
recovery is being entered due to a sus¬ 
pected PE failure, the faulted PE can 
resurrect itself by responding to the inter¬ 
rupt.) Using globally accessible registers in 
the bus interfaces, the PEs agree to enter 
recovery mode. 

Since the system has just faulted and is 
potentially in an unstable state, only one 
PE is allowed to execute recovery code at 
a time. Each PE performs the following 
sequence of steps: (1) find kernel memory; 
(2) make indictments; (3) complete an in¬ 
progress flush; and (4) complete an in¬ 
progress system call. We describe each step 


(1) Each PE must be able to run all of 
the kernel code to complete the 
recovery process. This must be pos¬ 
sible in spite of the system’s having 
suffered an arbitrary single-point 
failure. If the failed element is an 
ME, some kernel code may be lost. 
This is avoided by requiring that ker¬ 
nel code be shadowed in ME mem¬ 
ory. Therefore, the PE begins by 
executing code in its local PROM 
that finds the ME memory contain¬ 
ing the kernel. If no MEs containing 
kernel code have failed, this is a 
trivial matter. Otherwise, it must 
interpret hardware registers to find 
shadow copies of failed MEs. 

(2) Next, the PE attempts to find the 
cause of the fault by executing a 
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short diagnostic analysis to deter¬ 
mine if it can produce a fault. If so, 
it makes an indictment that states 
what it believes is causing the prob¬ 
lem. Later, the indictments from all 
of the PEs are gathered and convic¬ 
tions (that is, decisions to logically 
remove elements from the system) 
are made. An individual PE is not 
allowed to make a conviction on its 
own because it cannot distinguish its 
own problems from those in another 
module. For example, a PE may get 
no response from an ME because the 
PE’s bus outputs are malfunction¬ 
ing or because the ME is malfunc¬ 
tioning. Later, the system can tell 
whether more than one PE sees the 
fault by examining indictments and 
can, thereby, determine the nature 
of the problem. 

(3) A PE may be notified of a fault at 
any time. In particular, it may have 
been flushing its cache when it was 
stopped by fault notification. If so, 
it completes the double flush of its 
cache at this time. 

(4) After all PEs have executed these 
three steps, the system moves into 
the next phase of recovery. This 
phase is executed by a single PE, 
called the executive. Any PE may be 
the executive. A failure of the execu¬ 
tive is treated as an ordinary PE fail¬ 
ure and simply causes the recovery 
process to restart from the 
beginning. 

To give the executive a free hand in 
reconfiguring the system around convicted 
modules, reconfiguration begins in a state 
where no locks are held. To reach such a 
state, for each process that process was 
executing a system call at the time it was 
stopped by a fault notification, the execu¬ 
tive completes that system call. More pre¬ 
cisely, the executive forces all locks to be 
released by processes (one per PE) active 
at the time of the fault. It does this by 
sequentially running each such process 
until it owns no locks. 

Sequentially running processes in this 
way requires a special treatment of locks. 
When a process (actually, the kernel work¬ 
ing on behalf of a process) requests a lock 
that is not available, it must not spin, wait¬ 
ing for the lock to become available. Since 
only the executive PE is running processes, 
it would spin forever. Therefore, lock 
requests that cannot be immediately 
granted must cause the process to be 
blocked. Therefore, if the executive can¬ 


not obtain some lock, it blocks the proc¬ 
ess it was running and switches to another. 
When a process reaches a state in which it 
owns no locks, the executive stops running 
it. Since the kernel is deadlock-free, this 
activity is guaranteed to terminate. 

Next, the executive makes convictions 
as follows: If the intersection of all PEs’ 
indictments is a unique module, then that 
module is convicted. If not, then the infor¬ 
mation about the indictments is logged and 
no conviction is made. If similarly ambig¬ 
uous indictments result from a fault that 
occurs soon after that, the executive makes 
a tentative conviction despite the 
ambiguity. By switching out the indicted 
modules one-by-one, a state is eventually 
reached where the failed module is discon¬ 
nected from the system. 

If a fault is not repeatable, the executive 
assumes that the fault was a transient error 
and logs it. (Of course, it also logs perma¬ 
nent errors.) If a module experiences too 
many transients in a short time period, 
then it is treated as being permanently 
failed. 

After diagnosing the fault, the executive 
adjusts the hardware configuration tables 
in ME memory, which tell which modules 
are currently connected to the system and 
functioning properly. It then signals all 
PEs to resume normal operation. The 
entire recovery activity normally takes one 
to two seconds. 

Critical sections for fault tolerance. 
After the recovery activity is finished, 
processes that were running at the time of 
the fault are resumed. Since the hardware 
configuration may not be the same as it 
was at the time a process was interrupted 
by the fault, the correct resumption of a 
process must not depend in any way on the 
hardware configuration of the system. 
That is, a process state must contain no 
such information. 

This requirement is sometimes hard to 
arrange. At times, physical addresses of 
memory or register locations must be part 
of a process state. For example, when a PE 
initiates a DMA to move data from an IOE 
to an ME, the physical location into which 
the data is moved must be in the PE’s 
cache when the DMA is initiated. Suppose 
the PE flushed its cache at this point and 
then was interrupted by a fault. After 
recovery, it may try to resume execution by 
reinitiating the DMA in progress at the 
time of the fault. If the ME address it was 
using before the fault no longer exists in 
physical memory, such an attempt could 
result in accessing incorrect data. If the 


ME address references an ME that failed, 
recovery may never be completed. Each 
time the kernel resumes the context, it 
references the nonexistent ME and gets a 
fault, reinitiating recovery. 

To avoid these problems, whenever the 
kernel must work with physical hardware 
state information, it inhibits cache flushes. 
To do this, it handles cache misses in a spe¬ 
cial way, to avoid cache flushes that would 
normally occur due to cache overflows. 
Such critical sections are always very short, 
usually just a few instructions. The over¬ 
head is incrementing a counter. 

User shared memory 

The kernel supports a segmented 
address space for each process. Each seg¬ 
ment is a contiguous address space map- 
able into any part of a process’s virtual 
address space. Segments can be shared 
among processes. Writable shared seg¬ 
ments provide an alternative to messages 
for interprocess communication. They are 
also useful for shared structures such as 
database lock tables. 

Synchronizing shared memory. Writa¬ 
ble shared segments pose the same mutual 
exclusion problem to processes that shared 
OS tables pose to the kernel, as discussed 
in the section entitled “The multiproces¬ 
sor synchronization problem.” To help 
processes synchronize access to shared seg¬ 
ments, the kernel supports semaphores. 
Semaphores are implemented in kernel 
memory. Since they are concurrently 
accessible by PEs, they are stored in mem¬ 
ory protected by one or more test-and-set 
locks. (As for all shared kernel memory, 
the number of locks depends on the num¬ 
ber of partitions needed to limit lock con¬ 
tention.) So, to request or release a 
semaphore, the kernel must set and release 
the lock that protects access to the 
semaphore. 

A process uses a semaphore to protect 
accesses to a writable shared segment in the 
same way that the kernel uses locks to pro¬ 
tect access to shared kernel memory. 
Before accessing the segment, it requests 
the semaphore that protects access to the 
segment. After the access is complete, it 
releases the semaphore. 

Before accessing the segment, the pro¬ 
cess seeks to invalidate its cache to ensure 
it gets a fresh copy of the shared segment. 
This results from requesting the sema¬ 
phore, which entails setting a lock and 
invalidating a non-dirty user cache. After 
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accessing the segment, the process seeks to 
flush its cache to make its updates to the 
shared segment available to other 
processes. This results from releasing the 
semaphore, which entails setting and 
releasing a lock that in turn automatically 
causes a cache flush. 

Using shared writable segments, users 
can implement other interprocess commu¬ 
nication primitives. In particular, they can 
implement virtually any form of message 
passing. 

A fault recovery problem. In the section 
entitled “The recovery process,” we indi¬ 
cated that only one PE may flush at a time. 
The main reason for this restriction is the 
recovery of shared segments after a power 
failure. When power fails, all processing 
is interrupted. However, battery backup 
keeps MEs alive for up to 20 minutes or 
until power is restored. When power is 
restored, the system follows its usual 
recovery procedure. 

Suppose two PEs are executing 
processes that have access to the same 
shared segment. When power fails, sup¬ 
pose both PEs are flushing, one to the pri¬ 
mary and one to the backup. In particular, 
suppose two cache blocks of the same page 
are being flushed, one by each PE. In this 
case, neither the primary nor backup copy 
of the page is consistent after the power 
failure because each copy contains the par¬ 
tial results of a flush. For each block, 
either the primary or backup copy is con¬ 
sistent; but, the kernel can only tell which 
blocks are the consistent ones by analyz¬ 
ing which shared data structures are 
covered by which locks, which cache 
blocks hold which data structures, and 
which locks are held by each PE flushing. 

This analysis can be avoided if only one 
PE at a time is permitted to flush its cache; 
this restriction is currently used. Serializ¬ 
ing flushes this way may degrade perfor¬ 
mance by preventing both buses from 
being used concurrently for flushes by two 
PEs. However, while one bus is being used 
for a flush, the other bus can service cache 
misses (on PEs whose caches are not being 
flushed) and do DMAs from the IOE. We 
therefore believe that the performance 
degradation is small. 

T his article has presented the archi¬ 
tecture of a tightly coupled multi¬ 
processor that attains a high level 
of fault-tolerance using hardware fault 
detection and isolation and software fault 
recovery. Through a combination of lock¬ 
ing, shadowed memory, and controlled 


flushing of non-write-through cache, the 
kernel maintains a consistent main mem¬ 
ory state recoverable from any single-point 
failure. 

We believe that the cost of fault- 
tolerance in this architecture is relatively 
low. In the absence of failure, which is the 
normal mode of operation, most redun¬ 
dant modules contribute to overall system 
performance. All nonfailed processors 
perform useful work, with no dedicated 
backups. The dual buses operate indepen¬ 
dently. And mirrored disk controllers and 
devices add to the bandwidth of reads. 

Several costs are associated with fault 
tolerance. Among modules duplicated for 
fault tolerance, only the shadowed mem¬ 
ory does not add to system capacity. More¬ 
over, the double flushing of caches reduces 
effective bus capacity and processor speed, 
since the processor is stopped while the 
flush is in progress. 

Although there is cost associated with 
the electronics needed for fault detection 
functions, those functions allow the sys¬ 
tem to automatically self-diagnose its 
errors, thereby cutting the cost of testing 
during manufacturing and in the field. 

Even with Sequoia’s hardware fault 
detection and isolation, one reliability 
weakness of all tightly coupled architec¬ 
tures remains: Since all processors share 
the OS’s memory state, a software bug 
that corrupts that state may cause all 
processors to fail. Thus, the reliability of 
a tightly coupled computer depends on the 
reliability of its OS. In this sense, the OS 
is truly an extension of the hardware. 
Therefore, it is especially important that 
OSs for tightly coupled computers be care¬ 
fully designed and tested for extremely 
high reliability.□ 
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A s the performance requirements 
of advanced digital signal 
processing applications such as 
radar and sonar become steadily more 
stringent, the computational power 
needed to implement these systems 
increases. Indeed, specified processing 
rates frequently necessitate the use of 
specialized hardwired devices due to the 
insufficient computation and input/out¬ 
put bandwidth of conventional computer 
architectures, even when coupled with a 
commercial back-end processor such as a 
Cray. Major drawbacks to the hardwired 
device solution include a high development 
cost and an inflexibility with respect to 
future system modifications. 

An alternative solution is to use a num¬ 
ber of commercial programmable proces¬ 
sors, interconnected in some manner. 
Some of the difficulties encountered with 
this approach are: implementation of the 
data and control intercommunication net¬ 
work; system integration and processor 
synchronization; mapping or partitioning 
of the signal processing algorithm onto the 
array of processors; and programming, 
program testing, and debugging of each 


— 


This parallel 
processing architecture 
for real-time digital 
signal processing has 
demonstrated 
virtually 100-percent 
data processing 
efficiency in a 
number of areas. 


individual processor and the system as a 
whole. In particular, the overheads result¬ 
ing from the intercommunication between 
the processing units ensure that these 
highly composite systems typically operate 


at a fraction of their maximum theoretical 
capacity. An interesting tutorial account 
of these architectural approaches to signal 
processing problems may be found in 
Allen. 1 

This article describes a unique parallel 
computer architecture designed to meet 
the needs of modern digital signal process¬ 
ing systems requirements. Motorola’s 
Teamed-Architecture Signal Processor (T- 
ASP) is a field-proven, commercially 
available optimal system solution to the 
extremely high computation and I/O rates 
encountered in modern digital signal 
processing environments. 

T-ASPs are in use on board Canadian 
frigates for both passive and active sonar 
applications. They are used for both com¬ 
mercial and government satellite data 
processing and are under consideration to 
be the preferred signal processor for the 
Canadian Radarsat program. 

The design of T-ASP involves the con¬ 
sideration and implementation of many 
architectural concepts used to enhance the 
performance of a computer. These include 
programmability, parallel processing, vec¬ 
tor processing and pipelining, memory 
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Figure 1. T-ASP block diagram. 


interleaving, double cache memories, mul¬ 
tiple high-speed I/O interfaces, and seg¬ 
mentation of the processors for 
elimination of both CPU and data- 
handling overhead. These constructs are 
used in such a manner that the T-ASP 
design goal of virtually 100-percent data 
processing efficiency with no overhead has 
been achieved in a variety of applications. 
Indeed, typical applications yield efficien¬ 
cies of about 99 percent. 2 

The T-ASP architecture (see Figure 1) 
alleviates many of the problems encoun¬ 
tered in real-time applications through its 
use of a tightly coupled framework within 
which two, four, or eight processing units 


operate in parallel. Hence, T-ASP may be 
referred to as an array processor since an 
array processor is simply a computer 
whose architecture is structured upon an 
array of processors. Each of the arithmetic 
processors in T-ASP is a fully pipelined 
vector processor. Perhaps a more precise 
classification of T-ASP is made in terms 
of Flynn’s taxonomy wherein T-ASP is 
categorized as SIMD (single instruction 
multiple data). 3 However, even this is not 
a complete description since the “teamed- 
architecture” aspect of T-ASP allows an 
extra degree of freedom in that not only 
may each arithmetic processor operate on 
its own data, but the processors may coop¬ 


erate in order to work together in groups 
on the same set of data. 

T-ASP is also classified as a signal 
processor due to its complex floating-point 
word format and a hardware and software 
architecture optimized for fast Fourier 
transform-related signal processing appli¬ 
cations. 4 (See the section entitled “Real¬ 
time digital signal processing” for a discus¬ 
sion of the FFT.) For this class of applica¬ 
tion, T-ASP, fully configured with eight 
processing units, will sustain arithmetic 
execution at 320 million floating-point 
operations per second. An indication of its 
level of optimization is given by the follow¬ 
ing benchmarks: 
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(1) A 1024-point one-dimensional com¬ 
plex FFT executes on an 8.5-nanosecond 
Cray X-MP (the CFFT2 routine in the 
SCILIB library) in 0.4037 milliseconds 5 
and on an eight-arithmetic-unit T-ASP in 
0.16 milliseconds. 

(2) A two-dimensional 512-point by 
512-point complex FFT executes on the 
FPS 5430 array processor in 0.5 seconds 6 
and on an eight-AU T-ASP in 0.074 
seconds. 

A detailed discussion of the T-ASP 
architecture may be found in Bowen. 7 
However, we should point out that the text 
is inaccurate in some areas, especially with 
respect to its analysis of I/O bandwidths. 


Real-time digital signal 
processing 

Digital signal processing 8 concerns the 
algebraic processing of sequences or vec¬ 
tors of numbers which usually represent 
external signals. It is used in a variety of 
applications including communications, 
radar, sonar, speech, and seismology. For 
example, in a radar application, the signal 
received from the antenna is first con¬ 
verted to digital form and then digitally 
processed to extract information regard¬ 
ing the absence or presence of aircraft. If 
any targets are detected, their positions 
and velocities are estimated. In another 
application, a modem in a communica¬ 
tions link will employ digital signal 
processing techniques to equalize the 
received signal, perform echo cancellation, 
and detect and estimate the received data 
bits. 

Real-time signal processing often makes 
significant processing demands. The pro¬ 
posed Canadian Radarsat satellite-borne 
synthetic aperture radar system for 
monitoring the Arctic will require a digi¬ 
tal signal processing machine capable of 
storing 100 million complex words of data, 
handling an input data rate of 120 million 
complex words per second, and processing 
at a rate of 8000 Mflops. 

Digital signal processing most com¬ 
monly concerns digital filtering and spec¬ 
tral analysis. Since we can regard spectral 
analysis as the filtering of data with a set 
of bandpass filters, we could say that the 
most important operation in digital signal 
processing is the convolution (or correla¬ 
tion) operation. From time-frequency 
duality, correlation in the time domain 
may be performed via multiplication in the 
frequency domain. The fast Fourier trans¬ 





form provides an extremely efficient 
mechanism for transforming data between 
the time and frequency domains. By 
employing the FFT for correlation oper¬ 
ations via the frequency domain, a tremen¬ 
dously computationally efficient “fast 
correlation” algorithm is created. As a 
result, an important measure of merit for 
a signal processing computer is its ability 
to perform FFTs. 

The FFT is an elegant algorithm for the 
efficient implementation of the discrete 
Fourier transform (DFT), which is itself a 
periodic (in both the time and frequency 
domains) Fourier transform. An A-length 
FFT where A is a power of two may be 
implemented by what is referred to as a 
radix-2 algorithm, where there are log 2 (/V) 
stages, each consisting of N/2 complex 
“butterfly” operations of the form A ± 
B *C. 

Along with the FFT, the two other oper¬ 
ations frequently required in digital signal 
processing applications, such as radar and 
sonar, are heterodyning and beamform¬ 
ing. In the heterodyning operation, the 
data is shifted in frequency by vector mul¬ 
tiplying the data in the time domain by a 
phasor rotating at the appropriate fre¬ 
quency. Because of the time-frequency 
duality, data may also be shifted in time by 
heterodyning the FFT of the data. Time 
shifting is required for beamforming (see 
Figure 2) where the data received from a 


number of sensors are shifted in time and 
summed to steer the array of sensors in a 
desired direction. The required time shift¬ 
ing may either be performed in the time 
domain by delaying the data from each 
sensor and summing across the data (a 
time domain beamformer) or by forming 
the FFTs of the data from each sensor, 
multiplying across the FFTed data with 
some appropriate set of phasors, and sum¬ 
ming the product (a frequency domain 
beamformer). 


Hardware architecture 
design considerations 

The fundamental principle in the design 
of the T-ASP architecture is the complete 
elimination of all data processing over¬ 
head or, equivalently, the achievement of 
100-percent data processing efficiency 
within the context of real-time digital sig¬ 
nal processing. 

A signal processing architecture is said 
to be 100-percent data processing efficient 
if the computer is kept continuously busy 
executing arithmetic operations on data. 
Data processing overhead is defined as 
that percentage of the elapsed time that the 
computer spends doing other than arith¬ 
metic operations on data. Using this defi¬ 
nition, program bookkeeping aids such as 
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Figure 3. Arithmetic unit teamwork. 


pointers are not considered data. Pointer 
and address manipulation are considered 
part of the data processing overhead. It is 
convenient to consider data processing 
overhead as comprised of two separate 
components: code-execution overhead 
and data-handling overhead. Code¬ 
execution overhead includes all code han¬ 
dling and execution and program book¬ 
keeping. Data-handling overhead includes 
all data transfers to and from the process¬ 
ing units. 

Digital signal processing algorithms are 
usually characterized by the requirement 
that much identical processing is per¬ 
formed on many items of data. Vector 
data processing is most efficiently imple¬ 
mented with minimum overhead in pipe¬ 
lined, vector processors. 3 Moreover, by 
using a number of vector processors con¬ 
figured in a parallel array as in an SIMD 
architecture, a number of vectors of data 
can be processed at the same time with a 
further improvement in processing speed. 

Some SIMD machines are inefficient in 
that each processor can only process data 
local to itself. If a given processor has to 
use the data local to another processor, a 
significant data-handling overhead may 
exist, thereby reducing the data processing 
efficiency. An example of this scenario in 
signal processing applications is the com¬ 
putation of an FFT. Each stage of the FFT 
can be considered a straightforward vec¬ 
tor butterfly operation, 4 which can be 
partitioned across the array of vector 
processors. However, between stages, the 
data will have to be reordered so as to 


maintain locality. 

Using a teamwork approach, T-ASP 
eliminates this type of data-handling over¬ 
head by permitting the processors to work 
either individually or in groups. As a 
result, each processor works cooperatively 
with other processing units with no 
decrease in data processing efficiency. 

The topology of the interconnection 
network 9 between the processors is a 
cube (see Figure 3), optimal for FFT-based 
processing. A benefit of this teamed 
architecture is the ability to perform very 
large vector operations. A 32-byte FFT 
might be very cumbersome on other sys¬ 
tems, if possible at all. In T-ASP, a sim¬ 
ple instruction will perform with 
100-percent data processing efficiency. 

Any signal processing algorithm will 
involve the continual feeding of the 
processors with raw data and the storage 
of intermediate results for some future 
purpose. This major contribution to data- 
handling overhead is virtually eliminated 
in T-ASP via the use of a structure consist¬ 
ing of two sets of cache memories. In this 
context, a cache memory is a high-speed 
buffer memory inserted between the high¬ 
speed processors and the large data or 
working memory. 

The dual cache memory structure means 
that, while data is being transferred 
between one set of cache memories and 
working memory, the processors can proc¬ 
ess the data in the other set of cache mem¬ 
ories. When the processors finish 
processing the data in their set of cache 
memories, the two sets of cache memories 


are switched and the operation is repeated. 
By properly balancing the processing 
bandwidth against the cache memory¬ 
working memory transfer bandwidth, this 
structure ensures that the processors are 
continually fed with data, eliminating any 
data-handling overhead and thus main¬ 
taining maximum data processing effi¬ 
ciency. 

It is evident that there can be a large 
number of activities under execution at 
any given time, including 

(1) external device communication for 
overall processor control, 

(2) data-handling pointer and address 
manipulation, 

(3) execution of data-handling instruc¬ 
tions, 

(4) data I/O, 

(5) data-processing pointer and address 
manipulation, 

(6) control of the multiple processing 
units, and 

(7) execution of the data processing 
instructions. 

To maximize the overall system effi¬ 
ciency by allowing all seven activities to 
execute in parallel, each activity must be 
capable of executing independently. In 
effect, another dimension of parallelism 
has been added to this requirement of an 
SIMD parallel array of vector processors. 

T-ASP implements this seven-fold par¬ 
allelism by means of three controllers, a 
communications controller unit (CCU), a 
transfer controller unit (TCU), and an 
arithmetic controller unit (ACU) (Figure 
4). The CCU simply provides communica¬ 
tions channels to the outside world. The 
TCU and the ACU are each split into two 
sides, referred to as the left-hand side 
(LHS) and the right-hand side (RHS). The 
RHS of the ACU controls the operation of 
the parallel array of processors or arith¬ 
metic units (AUs) that perform the actual 
data processing. The RHS of the TCU is 
a parallel processor controlling both the 
execution, of the data-handling instruc¬ 
tions that involve the transfer of data 
between cache memory and working mem¬ 
ory, and the data I/O to working memory. 
Each RHS obtains its control information 
from its LHS. Each LHS is an identical 
fully pipelined conventional computer 
designed and built in-house. They provide 
a normal code-execution environment 
except for data-processing instructions 
(ACU) or data-handling instructions 
(TCU). These instructions are passed to 
the RHS, whereupon the LHS continues 
normal code execution. Since in both the 
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Figure 4. T-ASP parallelism. 


TCU and the ACU the LHS executes at the 
same time as the RHS, code-execution 
overhead is avoided. 

A significant factor in the data-handling 
overhead incurred in most machines is the 
data reordering required in virtually all sig¬ 
nal processing algorithms. Some common 
examples of reordering include matrix 
transposition (frequently referred to as 
cornering) and bit-reversing 8 of data out¬ 
put from an FFT. This overhead is elimi¬ 
nated in T-ASP by combining a 
generalized working memory interleaving 
scheme and a hardware-supported, 
programmable reordering switch matrix 
between cache memory and working mem¬ 
ory (Figure 5). 

Since T-ASP is optimized for signal 
processing applications, the rate of 
processing of the complex data associated 
with radar and sonar problems is max¬ 
imized by having AUs that process com¬ 
plex numbers. For maximum efficiency, 
many fundamental signal processing 
algorithmic instructions such as FFTs, 
beamforming, and heterodyning are 
incorporated in hardware. A very large 
(64 million 40-bit words) working memory 
eliminates the data-handling overheads 
incurred when auxiliary host or bulk mem¬ 
ory devices are used. 



Figure 5. Data reordering. 


In signal processing applications of con¬ 
siderable complexity and high I/O rates 
within our I/O capacity of 3.5 megawatts 
per second, a knowledgeable programmer 
can achieve efficiencies on the order of 99 
percent. 2 


Hardware architecture 
implementation 

As shown in Figure 1, T-ASP consists 
essentially of a large working memory in 
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which data is stored, an array of pipelined 
vector processors to process the data (the 
multiple processing part of the SIMD con¬ 
cept), an arithmetic controller unit to han¬ 
dle the operation of the arithmetic units 
(the single-instruction part of the SIMD 
concept), dual cache memories to move 
data from working memory to the proces¬ 
sors, a transfer controller unit to handle 
the flow of data between cache memory 
and working memory, and an extra com¬ 
munications controller to handle the com¬ 
munications protocol with the outside 
world. 

Communications controller unit. The 

CCU is the overall controller and I/O 
scheduler for T-ASP and does not require 
a high processing speed. It is a DEC 
PDP-11 minicomputer operating under 
the compact real-time operating system 
RSX-11. Primarily, its role in T-ASP is to 
provide gross signal processing program 
control, such as initiation and abortion, 
and to service the communications chan¬ 
nel through which program execution is 
synchronized with external devices. In 
addition, it has the capability to read data 
and write data to working memory, the 
TCU, the ACU, and the parameter RAM. 
The parameter RAM (see the section on 
arithmetic units) provides part of the 
mechanism required for efficient 
frequency-domain beamforming. 

Transfer controller unit. The primary 
role of the TCU is to control the transfer 
of data between cache memory and work¬ 
ing memory. It is programmed using the 
high-level MLP, an acronym for macro 
language processor. The MLP vector data- 
transfer instructions facilitate a wide vari¬ 
ety of data reorderings, all implemented 
“on-the-fly ” and defined by combinations 
of instruction type, working memory step 
size, and the switch matrix pattern. 

Switch matrix. The software-selectable 
switch matrix pattern allows data to be 
reordered in combinations of bit-reversal, 
spreading, and interleaving across various 
subsets of the cache memory. The switch 
matrix is performed by on-the-fly modifi¬ 
cation by the TCU of the cache memory 
addresses of the data being transferred 
between cache memory and working mem¬ 
ory (see Figure 5). 

Arithmetic controller unit. The ACU 

controls the actual in-cache memory 
processing of data transferred from work¬ 
ing memory by the TCU. The RHS con¬ 


trols up to eight AUs, each with its 
associated cache memory. It is pro¬ 
grammed using the MLP. The MLP sca¬ 
lar and vector data-processing instructions 
facilitate the implementation of the actual 
signal processing algorithms. The wide 
variety of data processing instructions 
include 

(1) fast Fourier transforms, 

(2) vector addition, 

(3) vector multiplication, 

(4) vector multiplication and addition 
(one instruction), 

(5) vector dot product, 

(6) vector heterodyning, 

(7) vector frequency-domain beam¬ 
forming, and 

(8) scalar arithmetic. 

Each instruction can execute in a num¬ 
ber of different modes. A partial listing of 
the available modes follows: 

(1) complex operation (default), 

(2) double-precision real operations, 

(3) conversion from complex to double¬ 
precision real, and 

(4) conversion from floating point 
(default) to fixed point. 

Finally, without any execution time pen¬ 
alty, the output from the AU pipelines 
may be transformed by one of the follow¬ 
ing functions: signum, absolute value, 
negate, reciprocal, square root, square, 
sine, arcsine, cosine, arccosine, logarithm, 
and antilogarithm. 

Arithmetic units. The AUs have been 
optimized for the basic complex vector sig¬ 
nal processing operations on data in cache 
memory. Each AU consists of a coefficient 
memory, an extended heterodyning facil¬ 
ity, and a pipeline (see Figure 6). The pipe¬ 
line itself consists of a complex coefficient 
memory, a complex floating-point mul¬ 
tiplier, a complex floating-point accumu¬ 
lator/adder, a complex normalizer, and a 
complex functions board. 

The coefficient memory provides a fast 
method for accessing frequently used mul¬ 
tiplicative constants and is automatically 
utilized for the FFT, heterodyne, and 
beamforming operations. The extended 
heterodyning facility accesses the coeffi¬ 
cient memory to generate the uniformly 
rotating vectors used in heterodyning. A 
parameter RAM is also provided, into 
which the CCU can write the intersensor 
delays for beamforming. The parameter 
RAM, along with the extended heterodyn¬ 
ing facility, provides the set of phasors 
required for frequency-domain beam¬ 
forming operations. 


One of the inputs to the pipeline mul¬ 
tiplier is from cache memory. The other 
can be from either cache memory or 
coefficient memory. This latter operation 
is required for basic butterfly operation in 
an FFT. One of the inputs to the adder is 
from cache memory. The other is from the 
multiplier output. The adder outputs both 
the sum and difference of its inputs, thus 
forming the full butterfly (A ± BC). The 
outputs from the adder are fed to the nor¬ 
malizer and then to the functions board, 
where they may be transformed on-the-fly 
if so desired before being written back to 
cache memory. 

All components in the pipeline are 
designed around the T-ASP 40-bit word. 
The two T-ASP data formats are complex 
floating point and double-precision real 
floating point, as shown in Figure 7. These 
floating-point formats are well suited for 
signal processing applications. 

Each AU may be visualized as a vertex 
in a cube (see Figure 3). Each may either 
independently process data in its own 
cache memory, or cooperate with others to 
process in parallel larger vectors that have 
been previously spread across all of the 
cache memories during the transfer of the 
data from working memory. As a result, 
on an eight-AU T-ASP with four-kilobyte 
cache memory per AU, it is possible to per¬ 
form an 8 *4K = 32K point FFT with a sim¬ 
ple instruction. 

Cache Memory. T-ASP employs a dual 
cache memory architecture to eliminate 
the data-handling overhead. T-ASP has 
one cache memory pair per AU. Each 
cache memory has a capacity of 4096 
40-bit words. During each AU cycle (250 
nanoseconds), two read and two write 
operations can be performed in each cache 
memory. This corresponds to the two 
inputs and outputs required for each but¬ 
terfly of an FFT. 

The cache memory pairs are grouped 
into two 32-kilobyte-word sections so that 
working memory has access to one section 
while the AUs access the other section. 
When data processing in the AUs has com¬ 
pleted, and working memory to cache 
memory transfers have completed, the two 
32-kilobyte cache memory sections are 
interchanged. 

Working memory. Working memory 
provides external devices with data storage 
up to 64 million 40-bit words and is seg¬ 
mented to allow simultaneous access of 
one word per segment per memory cycle 
(see Figure 8). It also provides access along 
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Figure 6. Arithmetic unit block diagram. 


different dimensions of an array at the [ 
maximum transfer rate, if at least all but | 




one of the dimensions are powers of two. 
Working memory has two ports: one for 
cache memory and the other for external 
devices. 

Complex Number 



Working memory accesses cache mem¬ 

Real mantissa 

16 bits 

two's complement 

ory globally. Switch matrix patterns are 
implemented on data transfers between 
cache memory and working memory. 




Imaginary mantissa 

16 bits 

two's complement 

whereby a vector in working memory can 
be rearranged across the global cache 
memory (spread, bit reversed, etc.). 

Input/output interface. The I/O inter¬ 
face is the data interface between working 
memory and external devices. The I/O 
interface is completely under the control 
of external devices, in that the external 




Common exponent 

| 8 bits 

two's complement 

Double-Precision 1 

Number 


devices can initiate both the input of data 
to working memory and output of data 

Mantissa 

31 bits 

| two's complement 




from working memory. The external 
device can select the initial working mem¬ 
ory address, the working memory step 
size, the data format (see Figure 9), and the 
direction of data transfer. 

Exponent 

| 8 bits | 

two's complement 





Sixteen I/O devices may be connected to 
the I/O interface on T-ASP, with only one Figure 7. T-ASP data format. 
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Segmented Working Memory 

• 2,4, or 8 segments 

• 375 ns DRAM 

• 8 M words per segment 

• Parallel access increases data transfer rate 

• Unique cornering capability 


Figure 8. Working memory teamwork. 
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Where: On input to T-ASP 2000, X is ignored and assumed to be zero. 

On output from T-ASP2000, X is set to zero. 


Figure 9. I/O interface 40-bit formats. 
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device at a time having access to working 
memory on a priority basis. I/O transfer 
rates are controlled by the device. The 
maximum I/O rate for an eight-working- 
memory segment T-ASP, where the for¬ 
mat is specified as complex floating-point 
(40-bit) words, is 3.5 million 40-bit words 
per second. 

Device control interface. This is the 
mechanism by which T-ASP is syn¬ 
chronized with the external world. It is the 
channel for exchange of control informa¬ 
tion with external devices. For example, 
the external device might specify that data 
has been placed in working memory in a 
particular buffer via the I/O interface. 
Subsequently, T-ASP will inform the 
external device that the data has been 
processed and is in working memory in 
another buffer. 


Managing the hardware 

The hardware architecture of T-ASP is 
optimally matched to the real-time signal 
processing environment in the sense that 
it can achieve virtually 100-percent data 
processing efficiency with no overhead. 
Therefore, it is possible to reliably and 
accurately predict the execution time for 
any given signal processing algorithm 
implementation. This capability is critical 
to real-time signal processing algorithmic 
optimization. The timing analysis is most 
easily performed by examinating the struc¬ 
ture of the implementation. 

To effectively manage the dual cache 
memory architecture of T-ASP, a soft¬ 
ware construct called the token has been 
developed. Each token consists of three 
logical segments (see Figure 10): 

(1) Load cache memory with data from 
working memory. 

(2) Process the data in cache memory 
using the AUs. 

(3) Unload processed data from cache 
memory to working memory. 

The T-ASP operating system (TOS) is 
designed to thread together the flow of 
tokens issued by the executing tasks. 
Tokens are said to be threaded when the 
load and unload modules of one token are 
executed in parallel with the process mod¬ 
ules of another token (see Figure 11). In 
this way, the use of the machine’s capabil¬ 
ities is maximized in a multitasking envi¬ 
ronment. 

The following is the analysis and imple¬ 
mentation of a two-dimensional 1024-by- 
1024 point FFT. The machine under inves- 
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Figure 10. A single token execution. 
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Figure 11. Threaded token execution. 


tigation is a two-AU T-ASP with four 
working memory segments. The first step 
in the timing analysis is to ensure that the 
individual tokens are processing bound, as 
opposed to transfer bound. The ACU 
processing of eight length 1024 FFTs 
requires 

8 * (1024/2)Log (1024) * (250/2)ns = 
5.12 ms 


The concurrent TCU load and unload of 
eight length 124 vectors each requires 

16 * 1024 * (375/4)ns = 1.536 ms 

Thus, each load/process/unload token is 
properly processing bound, where the time 
taken to load and unload the data is hid¬ 
den behind the time necessary to process 
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Figure 12. T-ASP 2000 operating system. 


the data. The first load module and the last 
unload module are not included in the cal¬ 
culation of the overall execution time of 
the two-dimensional FFT, since it is 
assumed that a preceding token will cover 
the initial load time overhead and a suc¬ 
ceeding token will cover the final unload 
time. For programming simplicity, some 
data-handling overhead has been intro¬ 
duced in the middle of the token map, 
where the first row to be FFTed cannot be 
loaded until the last FFTed column has 
been unloaded to working memory. The 
total execution time of the two- 
dimensional FFT is 

(2 * 1024/8) ACU modules + 1 
load + unload module 
= (2 * 1024/8) *5.12 ms + 

1.536 ms 
= 1.312s 

Experimentally, 100 executions of the two- 
dimensional 1024-by-1024 point FFT 
required 131 seconds. 

Software architecture 
design considerations 

As discussed, the primary design factor 
in the hardware design of T-ASP is the 
elimination of overhead to achieve 
100-percent data processing efficiency. It 
is crucial to the success of the machine that 
the system software not degrade this high 


level of real-time performance. To this 
end, a number of factors are critical to the 
design of the system software architecture. 

(1) Fast response, with minimum over¬ 
head, to external devices sending 
data or retrieving data from T-ASP. 
This is mandatory for a real-time 
system; otherwise, data will be lost 
and external devices will require 
large data buffers for temporary 
storage to make up for the inade¬ 
quate machine response time. 

(2) Proper use of the double cache 
memory system so the high level of 
processing efficiency that such a 
design offers is not reduced. 

(3) Minimal operating system overhead 
in order to decrease code-execution 
overhead and thus increase program 
efficiency and the accuracy and 
reliability of execution time analysis. 

(4) Nonintrusive on-line diagnostics 
software system for the proper 
maintenance of system integrity in 
real-time applications. 

(5) User-friendly software development 
and debugging that enables the user 
to proficiently design, code, and test 
the application software. 

Software architecture 
implementation 

T-ASP software consists of four parts: 
the T-ASP operating system, MLP pro- 


T-ASP operating system. TOS fully 
supports both multiuser and multitasking 
real-time program execution environments 
with virtually zero operating system exe¬ 
cution time overhead. TOS resides on the 
CCU, the TCU, and the ACU as shown in 
Figure 12. It is responsible for starting and 
aborting tasks running on the TCU and 
ACU. It can also be used to communicate 
with working memory, parameter RAM, 
and TCU and ACU tasks. On the CCU, it 
is essentially a kernel DEC RSX-11 oper¬ 
ating system, providing a compact envi¬ 
ronment for task execution. 

T-ASP programming language MLP. 

MLP is a careful match between signal 
processing applications and the signal 
processing capabilities of T-ASP. It 
represents an optimal solution to the effi¬ 
cient implementation of signal processing 
algorithms on T-ASP. MLP is a high-level 
structured digital signal processing lan¬ 
guage. Commonly used digital signal 
processing primitive operations such as the 
FFT, dot product, and vector multiply are 
single instructions. 

The MLP compiler accepts one source 
file and generates two object files, one for 
the TCU and the other for the ACU. 
Instructions for the TCU consist of work¬ 
ing memory to cache memory vector trans¬ 
fer instructions, in addition to LHS 
“housekeeping” instructions also used to 
control program flow. Instructions for the 
ACU consist of easily used vector arith¬ 
metic instructions expressed in algebraic 
format, in addition to LHS housekeeping 
instructions. 

T-ASP software utilities. T-ASP system 
software offers a conventional program 
development environment. An extensive 
array of software utilities exists to ease the 
program development burden on T-ASP. 
The utilities include a signal processing 
library, compilers, linkers, downloaders, 
debuggers, and working memory editors. 

T-ASP diagnostics. In addition to the 
usual climate-controlled computer rooms 
found in usual shore-based installations, 
T-ASPs have been sold for application in 
the rugged environments found in naval 
ships, and others are destined for use in 
aircraft and submarines. Diagnostics soft¬ 
ware forms a very important part of T- 
ASP system software for maintaining sys¬ 
tem integrity in such applications. Diag- 
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nostics software consists of an on-line and 
an off-line package. 

On-line diagnostics are designed for 
low-priority execution with the user’s soft¬ 
ware. They execute in the background, 
continuously exercising and checking all 
aspects of the hardware, such as working 
memory, cache memory, the AUs, the 
TCU, and the ACU. They report any 
errors detected and compile a status 
report. On-line diagnostics will isolate a 
fault to a macro functional level. 

Off-line diagnostics are designed to fur¬ 
ther isolate an error to the board level, at 
which point boards can be swapped to fix 
the machine. They are more thorough and 
can be used as a confidence test of the 
hardware. 
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T he design of machines capable of 
the massive concentration of 
computer power necessary to 
handle modern signal processing environ¬ 
ments, such as sonar and radar, is a com¬ 
plex task. Virtually all aspects of modern 
computer architecture must be utilized in 
an effort to gain the necessary execution 
rates. These theoretical concepts have been 
integrated to form the structure of the sig¬ 
nal processing computer T-ASP, one of 
the most powerful computers under cur¬ 
rent production. □ 
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The Source of Authority 
for Commercial Access 
Control 

Jonathan D. Moffett and Morris S. Sloman 
Imperial College of Science and Technology, London 


M odels of access control have 
historically been based on 
“friendly” academic or 
“autocratic” military requirements. In 
neither case has the question of the source 
of authority for access control decisions 
arisen. Commercial security policies differ 
from both of these in important respects, 
being based on control principles derived 
from auditing practice and legislation. 

Authority for the decisions which per¬ 
mit users to access resources needs to be 
considered explicitly and reflected in the 
policy model. Access control policies 
define the rules which regulate how peo¬ 
ple (and programs acting on their behalf) 
can access resources in a computer system. 
Five components make up an access con¬ 
trol policy: 

(1) Users may be people sitting at a ter¬ 
minal or workstation or the processes 
which run on their behalf within the com¬ 
puter system. The policy identifies what a 
user is allowed to do. 

(2) Resources are the programs, ser¬ 
vices, or data accessed by users. The policy 
specifies what resources a user can access. 

(3) Operations are the specific opera¬ 
tions which can be performed on a 
resource. Each resource type has a set of 
operations it can support. It is insufficient 
for the access control policy to specify that 
a user can access a resource; it must specify 
which operations the user is permitted to 



Access control 
systems for a 
company’s computers 
should mirror the 
organization’s internal 
control systems, based 
on the delegation of 
authority. 


invoke on the resource. For example, one 
user may be permitted to update a file, 
whereas another user may only read the 
file. 

(4) Authority is the legitimate power to 
make policy decisions. This article is 
mainly concerned with describing the way 
in which authority is delegated so as to 
ensure that access control is implemented 
in accordance with the policies of the 
management of an organization. 

(5) Domain is the boundary, containing 
resources or users, within which the 


authority applies. For example, a manager 
typically has authority over the resources 
and people in a department. 

We distinguish three levels of policies in 
this article, although we make no rigid dis¬ 
tinction among them: 

• General policies, which do not relate 
to a specific organization, such as the 
decision to give access control 
administration to security adminis¬ 
trators. 

• Specific policies, which are high-level 
decisions in a particular organization, 
such as the decision to give access 
control administration of the market¬ 
ing department of XYZ Co. to the 
security administrator in the data 
processing department. 

• Access rules, which are the specific 
decisions, made at a lower level, to 
allow particular users access to partic¬ 
ular resources. The term is equally 
applicable to capabilities or access 
control lists. 

User identification. A critical issue relat¬ 
ing to access control is identifying users. 
Computers do not naturally recognize 
people, and it was necessary to invent 
methods of enabling them to do so. The 
identification of people involves three 
stages: 

• Telling the computer who is using it: 
identification. 
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• Proving one’s identity: authenti¬ 
cation. 

• Associating a person with a process. 

Identification is achieved by creating a 

register of users and assigning each person 
a user ID. 

An authentication method, such as a 
password, magnetic card, or signature 
verification system, helps ensure that the 
user is in fact who he or she claims to be. 
It may be backed up by supporting evi¬ 
dence, such as the identity of the terminal 
from which the user is logging on. Authen¬ 
tication can be used at entry to the system 
(log on) or at other times during a user’s 
session. 

Since all actions of a computer are car¬ 
ried out by means of processes, the only 
way to associate a particular user with a 
computer’s actions is by binding his or her 
identity to a process. So, some (but not all) 
processes in a computer are associated 
with a person. For example, many file 
accesses are carried out in response to a 
request by a person, and the process car¬ 
rying out the request takes on that person’s 
user ID for the duration of the request. 

In a centralized computer system, it is 
assumed that once a person’s identity is 
associated with a process, all access con¬ 
trol decisions could be related to the per¬ 
son’s identity. However, in a distributed 
system the identity of a process is a real 
issue. There may not be a single control¬ 
ling operating system which can vouch for 
the identity of each process. Therefore, it 
was necessary to devise some means of 
authenticating processes to each other. 
The main contributors to this, Needham 
and Schroeder, 1 introduced a mutual 
authentication protocol for independent 
processes using a trusted authentication 
server as an intermediary. These tech¬ 
niques for the mutual authentication of 
processes have become a recognized part 
of the access control mechanisms for dis¬ 
tributed systems. 

Authority. The access control policy 
specifies the guidelines or general rules for 
deciding what operations—users in a 
domain—can perform on resources. In 
addition, the policy should specify the 
source of authority, that is, how access 
rights can be given to users. Authority 
relates to the management of both users 
(people) and resources. 

This article is concerned with how access 
rights are allocated to users in an organi¬ 
zation. In general, an access right moves 
through an organization by one person 
giving it to another. In a commercial 


Surveys indicate the 
actual threat from 
computer fraud is 
relatively small 
despite the potential 
for abuse. 


organization it is important to consider 
two things: Does the giver have authority 
over the resources to which he is giving 
access? Does the giver have authority to 
give access to the recipient? Only if both 
conditions are met can the access right be 
given. 

We will explain why authority is impor¬ 
tant for commercial systems and will show 
how it can be specified and checked. 


Commercial security 
requirements 

The three main influences which moti¬ 
vate the need for security in commercial 
organizations are protection of assets, 
auditing practice relating to public owner¬ 
ship of a company, and legislation. 

Protection of assets. The organization’s 
assets, whether money, goods, or propri¬ 
etary knowledge, need protection. The 
increased reliance upon computers to sup¬ 
port operations or even carry them out 
implies that, to an increasing extent, pro¬ 
tection of assets implies protection of com¬ 
puter resources against loss or corruption. 

The threats to an organization’s assets 
through its computers are by now well- 
known. They include 

• physical damage to computer 
equipment; 

• loss of vital operating data as a result 
either of physical damage or user 
action, whether accidental or 
deliberate; 

• unauthorized disclosure of confiden¬ 
tial information, directly or by infer¬ 
ence; and 

• fraud. 

Fraud in particular has attracted con¬ 
siderable attention. The potential to 


manipulate systems from a distance to 
steal from a company excites the public 
imagination. However, its importance 
should not be exaggerated. Surveys of 
actual computer-related fraud incidents 2 
indicate that the threat of computer fraud, 
even after allowing for under-reporting, is 
relatively small. Its actual overall incidence 
is a tiny proportion of the frauds commit¬ 
ted without the aid of specific computer 
techniques. But the potential for fraud in 
computers, if they are not well protected, 
increases with the ease with which they 
enable manipulation of assets. 

Auditing practice. Commercial organi¬ 
zations exist mainly to make profits for 
their owners. In some cases, such as pri¬ 
vately owned companies and professional 
partnerships, the owners are also the 
managers; but in the case of public limited 
companies the owners are shareholders 
who do not take part in the running of the 
company. 

The possibility of shareholders losing 
because of mismanagement of the com¬ 
pany has long been recognized. Therefore, 
all developed countries have laws requir¬ 
ing regular audits of each company to 
verify that the company’s profits and 
assets are truly stated in management’s 
reports to its shareholders. 

Auditors can and do verify the assets of 
the company directly and vouch for indi¬ 
vidual transactions (a balance sheet audit), 
but auditing practice has increasingly 
emphasized the auditing of the computer 
system itself (a systems audit). In this 
approach, the auditor assesses the validity 
of the operations which manipulate the 
resources in the computer systems. This 
means that all transactions which can be 
invoked by users are validated to ensure 
that they manipulate the resources in a 
constrained way so as to maintain the 
integrity of the resources. If it can be 
shown that the system can only perform 
valid transactions, then it is not necessary 
to log and check individual transactions to 
the same extent. 

Legislation. The Foreign Corrupt Prac¬ 
tices Act was passed by the United States 
Congress in 1977 in response to the world¬ 
wide scandal caused by the Lockheed brib¬ 
ery case. The company had evidently 
obtained much of its overseas business by 
corrupt means. The act applies to all for¬ 
eign subsidiaries of US-owned multina¬ 
tional companies. Mostly it concerns 
outlawing bribery and other corrupt prac¬ 
tices, but it also contains a requirement 
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that all of these subsidiaries must have 
effective systems of internal control over 
their transactions and assets. This includes 
the full recording of all transactions. 
Because of the severe penalties meted out 
in the past to firms which have committed 
ethical offenses in the USA, the Act has 
been taken very seriously by auditors, both 
internal and external, of US-based mul¬ 
tinationals. 

The data protection laws which now 
exist in most Western countries (such as 
the UK Data Protection Act, 1984) have 
also provided a strong motivation for secu¬ 
rity, as they require access to personal data 
to be allowed only when specifically 
authorized. 


Commercial security 
controls 

Access control mechanisms. These 
mechanisms permit access by a user to only 
those resources for which he or she has 
received authorization. On older systems, 
this may be done by associating passwords 
with individual resources, but the method 
is unsatisfactory because of the difficulty 
of sharing and lack of personal accounta¬ 
bility. 

Mechanisms associated with individual 
user identities provide potentially better 
control. Access control lists hold the rights 
in association with the resources to be 
accessed. Capabilities are rights held by the 
user until he or she comes to exercise it. 

However, our main concern is not with 
access control mechanisms and the proof 
of their security, but rather with access 
control policies and how access is 
authorized. 

Internal organization controls. Internal 
controls are not specific to computer sys¬ 
tems, nor are their principles laid down in 
legislation. Nonetheless, the main princi¬ 
ples are common ground among auditors 
and accountants. 3 The principles which 
most concern this discussion relate to 
transactions affecting assets: 

• The transactions must be authorized, 
meaning they must be carried out by some¬ 
one to whom authority has been duly 
delegated. 

• As far as practical, there must be 
segregation of duties and responsibilities 
so that no single person is in a position to 
misappropriate assets. A typical example 
of segregation of duties in a computer sys¬ 
tem is the requirement that creation of a 


Segregation of duties 
in a computer system 
can be difficult if the 
manager administers 
access rules for his 
section. 


batch of transactions on a computer be 
carried out by a different person from the 
one who approves and initiates them. 

Segregation of duties can be difficult to 
achieve in a computer system if the man¬ 
ager of a section is also responsible for 
administering access rules for the data 
used by his section. For example, if an 
accounting section consists of a supervisor 
and several clerks, typically the clerks will 
have authority to input transactions but 
not to approve them, while the supervisor 
can approve transactions but not input 
them in the first place. If the supervisor 
also administers access rules, segregation 
of duties cannot be enforced because the 
supervisor could change the rules to obtain 
the power to input transactions. The best 
way of avoiding this is to designate a secu¬ 
rity administrator with no line authority, 
but with the authority to administer data 
access rules on behalf of line management. 
The security administrator does not 
require, and should not have, access to the 
data. 

Other approaches—why they are not 
adequate. In contrast with the commercial 
world, the worlds in which access control 
have been developed take a simple view of 
authority. Initial formal approaches to 
access control were developed by the aca¬ 
demic world, but military requirements 
have more recently dominated the direc¬ 
tion of development. A1981 survey of for¬ 
mal models of computer security 4 
concentrated on provable security. Most 
recent papers have confirmed this trend. 

At first, models of access control 
reflected the academic’s friendly view of 
the world, in which freedom of access to 
information was a cornerstone. Access 
controls were minimal, 5 concerned more 
with controlling processes than people. 
Where people were included, 6 the exam¬ 


ples used were from a world in which the 
typical security threat was a student want¬ 
ing to take an advance look at an exam 
paper or alter grades. This world assumed 
widely scattered information ownership, 
and that information should be available 
unless there is a positive reason to protect 

The next type of model has dominated 
the past few years, since the military 
grasped the fact that physical security 
alone would not suffice to protect their 
computer systems. The USA Department 
of Defense Trusted Computer Evaluation 
Criteria, 1 first published in 1982, has 
served as its beacon. In this world of rigid 
compartments, decisions about access to 
information depend primarily on its secu¬ 
rity classification, enforced by mandatory 
security mechanisms. Flexibility is deliber¬ 
ately almost entirely designed out of the 
system. For the typical person handling 
classified data under military security con¬ 
ditions, security decisions are handed 
down by a superior officer; they are 
obeyed, not made. 

Military security emphasizes preventing 
access by unauthorized people, whereas 
commercial security emphasizes making 
sure people authorized for some access do 
not invoke unauthorized transactions. A 
high proportion of recent research into 
access control has focused on implemen¬ 
tations of provably secure software to 
meet the DoD model. 

So the two paradigms of access control, 
although poles apart in attitude, have had 
one quality in common: Neither has con¬ 
cerned itself much with the source of 
authority for access control decisions, in 
one case because access control is treated 
as a necessary evil to be minimized, and in 
the other case because decisions are made 
from above and are not to be questioned. 
This attitude has probably been 
encouraged by the very definition of 
“policy” to be found at the front of most 
works dealing with security. 8 “Policy” is 
described as a set of rules for providing or 
maintaining security, but the source of 
these rules is not referred to. 

Many people have assumed that security 
policies for commercial systems are either 
less friendly versions of academic policies 
or military policies with fewer teeth. Nei¬ 
ther is true. Considerations for commer¬ 
cial security policies differ in quality, 
because the principles of internal control 
take a much more sophisticated view of 
authority. Effective internal control can 
only be maintained at a reasonable cost if 
the access control system allows for the 
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controlled devolution of authority to 
designated people. This is a more stringent 
and more complicated approach than had 
been used until recently. 

A recent article 9 has recognized the 
problem and defined a set of rules for com¬ 
mercial security in a system which, if 
implemented, would maintain internal 
control by implementing principles of 
verification of integrity, authorization of 
procedures, and segregation of duties. But 
it has not considered the way in which 
authority is distributed in the system. 

Authority 

We can define authority as the legiti¬ 
mate power to control or manage. Two 
types of authority affect access control: 
authority relating to people and over 
resources. A person (usually a security 
administrator) who issues a user access 
rights to perform operations on a resource 
needs both authority to grant access rights 
to that user and authority over the 
resource. He or she has two domains of 
authority: 

• The organizational domain defines 
those users in an organization, normally 
defined by their positions (see below), for 
whom the person with authority can per¬ 
form security administration services. This 
may be unlimited—the whole organization 
—or it may be limited to a particular sec¬ 
tion of the organization, such as the mar¬ 
keting department. The security adminis¬ 
trator can only give access rights to a per¬ 
son occupying a position within his or her 
organizational domain. 

• The resource domain defines the set of 
operations on resources to which the secu¬ 
rity administrator has authority to grant 
access rights. 

The system must permit a security 
administrator to give an access right if and 
only if the recipient occupies a position in 
the administrator’s organizational domain 
and the resource falls in the administra¬ 
tor’s resource domain. 

The source of authority. Traditionally, 
the source of authority over use of 
resources or assets is vested in their owner. 
For example, many file systems consider 
the creator of the file the owner, who can 
issue access rights to other users and delete 
the file. However, in a commercial system 
it is meaningless to consider the creator of 
a bank account file the owner of that file, 
with authority over it. 


Segregation of duties 
applied to computer 
systems defines the 
organizational domain 
of the security 
administrator to 
exclude his or her own 
position. 


Strictly speaking, the shareholders of a 
company own the resources in that com¬ 
pany. In many commercial organizations, 
ownership is separated from management, 
so the owners (shareholders represented by 
a board of directors) delegate authority to 
management. It is useful to distinguish 
between full control and limited control 
such as a security administrator’s control 
over access rights to a file. We will use the 
term owner to represent the person (or 
position) who has full control over a 
resource. You should recognize that this 
distinction begs some questions (such as, 
what is “full”?), but it stands up reasona¬ 
bly well in practice. 

Most organizations are structured hier¬ 
archically, with a board of directors that 
delegates authority to top management, 
who in turn delegate some authority to 
departmental management, and so forth. 
The eventual owner of the resource is thus 
the person to whom full control of it has 
been delegated. 

The process shows most clearly in the 
delegation of monetary budgets. The 
board of a company agrees on a total 
budget for the coming year. The money in 
the budget is then divided between major 
parts of the company, such as manufactur¬ 
ing, marketing, and research, in propor¬ 
tions determined by the board. Each 
major division divides its available budget 
appropriately among the activities it car¬ 
ries out. In most well-run companies, the 
budgeting process is carried out in a for¬ 
mal and visible manner, with each man¬ 
ager knowing the extent of his or her 
budget and the limits of his or her 
authority. 

For obvious reasons, delegation of 
authority appears in its most developed 


form in the case of monetary budgets. 
However, the concept of delegated 
authority also applies in other areas, such 
as the management of personnel in the 
organization. It has also proven a useful 
concept for data processing. 

Numerous problems arose in the earlier 
days of data processing, when the com¬ 
puter department effectively “owned” all 
of computing; often computer people gave 
users what they thought would be good for 
them, not what the users actually wanted. 
The idea therefore arose that applications 
and data should be treated in the same way 
as other company assets, with ownership 
being well-defined. Thus, the director of 
a marketing department has ownership of 
its applications and data, but can delegate 
that ownership. The director may delegate 
internally to subordinates, such as a user 
project manager. He or she may also del¬ 
egate limited authority externally to the 
data processing department, such as the 
tasks of development of new systems and 
operation of production systems. 

In well-developed companies, the dele¬ 
gation of authority (ownership or access) 
over computer resources is nearly as for¬ 
mally defined as for monetary budgets. 
The source of authority for use of these 
resources is a chain of formal decisions 
which can be traced back to decisions of 
the board of directors managing the com¬ 
pany for its owners, the shareholders. 

Three classes of rights can be delegated: 

• Ownership gives total control over a 
resource. 

• Give-right permits the holder to give 
an access right to a third party. A give- 
right applies to a specific operation on a 
particular resource instance. The owner of 
a resource may delegate the authority to 
issue access rights to that resource to a 
security administrator. 

• Access right gives the authority to per¬ 
form a specific operation on a particular 
resource instance. In general, the posses¬ 
sion of an access right does not automati¬ 
cally permit the holder to transfer it to 
another user. 

Possession of one type of operation 
right may imply another. For example, 
write access to a file may imply read access 
in some systems. 

The authority of both the owner and the 
security administrator can be traced back 
to formal decisions of delegation of 
authority. 

Access control systems sold commer¬ 
cially naturally recognize the facts of life, 
and mostly represent lines of authority 
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reasonably satisfactorily. For example, all 
the major access control systems for IBM’s 
large systems, such as IBM’s own 
Resource Access Control Facility (RACF), 
define a security administrator role sepa¬ 
rate from normal data access or owner¬ 
ship. It is possible to set up the resource 
domain for the security administrator so 
that he or she cannot obtain access to data, 
but must rely upon the authority of a 
different security administrator for this 
purpose. Only the rarely used bootstrap¬ 
ping user ID, whose use can be monitored, 
gives unlimited power. Even the rather old 
Multics system 10 recognizes the possibility 
of separating access from administration, 
although it does not claim to do so in a very 
satisfactory fashion. 

Formal academic models, on the other 
hand, have so far given little recognition 
to control principles as outlined above. 
Lampson 5 tightly bound the security 
administrator’s authority to give-rights 
with the access rights, by means of a spe¬ 
cial property which, when associated with 
an access right, also allows that right to be 
passed on. Snyder 6 took the same 
approach, with a “grant” exercisable only 
if the grantor possessed the relevant access 
right. A more recent article 11 recognized 
that the security administrator’s authority 
to give access should not be bound in with 
the access right itself. In this model, which 
dealt with distributed authority, the giving 
of access was independent of the access 
right and dependent upon the degree of 
trust between different authorities. How¬ 
ever, the setting up and changing of the 
trust relationship was outside the scope of 
the model. 


Who guards the guardians? This ques¬ 
tion did not arise with computer 
systems—it has been asked regularly since 
Plato’s time. Its age indicates that we can¬ 
not expect to find a complete and final 
answer. 

The question translates naturally to the 
subject of access control. What is the point 
of giving someone the authority to grant 
access rights to other people, but refusing 
access to that person? He or she can always 
change the rules to obtain access. 

What prevents a larcenous bank clerk 
from taking the bank’s money? The 
answer is, sometimes nothing. But the risk 
can be 

• limited in magnitude, 

• reduced in likelihood by making it 
more difficult, and 

• made detectable, so that the culprit 


can be caught or, better, deterred 
from doing it in the first place. 

The risk can be limited in magnitude by 
placing upper limits on a clerk’s authority. 
Similarly, the resource domain for a secu¬ 
rity administrator does not need to include 
all the data in the system, but only that 
data whose access the administrator must 
control. 

The risk of theft can be reduced by mak¬ 
ing it more difficult. Most organizations 
have an upper limit for the financial 
authority of one person and require the 
cooperation of two people for authorizing 
sums above the limit. This can also be 
implemented in computer systems—the 
segregation of duties principle again. A 
simpler method of doing this is to define 
the organizational domain of the security 
administrator’s powers to exclude that 
position; someone else should control the 
administrator’s access. 

The risk can only be limited, not 
removed, because any security system 
must be bootstrapped in, allowing the 
bootstrapper the possibility of illicit 
access. However, the risk can be confined 
to well-defined situations monitored by 
personal supervision. 

The risk can be made detectable. Daily 
reconciliations and regular audits in a 
bank are intended to ensure that, if a clerk 
does make off with a handful of notes, the 
loss will be rapidly detected and traced to 
its perpetrator. Similarly, the actions of a 
security administrator can be logged and 
should be monitored regularly by someone 
else. Even if the administrator can turn off 
the logging, it is normally possible to 
ensure that the act of turning off logging 
is recorded securely, such as on a hard¬ 
copy console log or WORM (write-once 
read-many) media. The bootstrapping 
process is the most vulnerable to suppres¬ 
sion of logging and, therefore, needs the 
most supervision. 

There is nothing new, then, in the ques¬ 
tion of who administers the security 
administrators. Although not solved, the 
problem is limited by narrowing the scope 
for misbehavior, recording all significant 
actions, and concentrating personal super¬ 
vision on the main point of vulnerability 
in the process. 

Policy 

Policy making. Once we have recog¬ 
nized the need to incorporate the authority 
structure of an organization into any 
model of access control, the inclusion of 


the organization’s policies becomes essen¬ 
tial. Even if a manager has a monetary 
budget, he or she still does not have unre¬ 
strained freedom to spend the money. 
Policy decisions made by higher manage¬ 
ment constrain the manager to act in ways 
consonant with the interests of the com¬ 
pany as a whole. The manager recognizes 
the force of these decisions because they 
have been made in accordance with the 
authority structure of the company. A 
policy decision made by the marketing 
director is not binding on the manufactur¬ 
ing division unless the board has given the 
director authority in that particular area. 
Similarly, access control policies are rules 
made by the appropriate authority which 
act as constraints on the giving of access 
rights. 

It helps to be rather more specific about 
policy-making, while recognizing that this 
prescriptive picture may be false for many 
organizations. Most organizations have a 
steering committee or other body to which 
the board has delegated the task of over¬ 
seeing and policy-making for the comput¬ 
ing activity. Access control policies are 
those decisions of the steering committee 
which affect the way that day-to-day 
access control is carried out. They can thus 
be seen as grounded firmly in the authority 
structure of the organization, rather than 
arising spontaneously. 

Examples of general access control poli¬ 
cies include: 

• Access rules should be made about 
positions, not people, in order to ensure 
that they continue to be valid after person¬ 
nel changes. 

• A security administrator should only 
be able to grant access to people within his 
or her defined organizational domain. 

• A security administrator should only 
be able to grant access rights to resources 
in his or her defined resource domain. 

• A manager should be able to specify 
the people under his or her control who 
form an organizational domain and dele¬ 
gate access control authority over this 
domain to a security administrator. 

• The person who has access to a 
resource domain (such as a directory) has 
access to all resources and subdomains 
contained in that domain unless there is a 
more specific rule to the contrary. 

Needless to say, a typical organization 
will not necessarily adopt all of the above 
policies. 

Policies are either mandatory or discre¬ 
tionary. Security administrators and users 
are forced to follow mandatory policies, 
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preferably because the policies are 
enforced by the system, but otherwise by 
means of normal organizational principles 
of internal control. Discretionary policies, 
on the other hand, leave the system 
administrator and possibly the user with 
some discretion in applying them. 

An example of a mandatory policy is 
that only specified operations (transac¬ 
tions) can be invoked on authorized 
resources. 9 This is implicit in object- 
oriented systems, as resources and their 
operations are specified as a single entity. 
Otherwise, explicit security mechanisms 
are required. 

Role of security administrators. We dis¬ 
cussed the role of security administrators 
briefly under authority, introducing the 
concepts of organizational and resource 
domains. This section describes how the 
concepts can be used to define security 
policy. 

Whether owners give out access rights or 
delegate this to security administrators is 
itself a security policy decision. In both 
cases, the system should perform the fol¬ 
lowing checks when an access right is given 
to a user: 

• Does the giver administer the recipi¬ 
ent? In other words, is the recipient in the 
giver’s organizational domain? 

• Does the giver have authority over the 
resource for the requested operation? In 
other words, is the resource in the giver’s 
resource domain? 

Interestingly, Snyder’s formal access 
model 6 deals explicitly with administra¬ 
tion rights over the user. His “grant” rela¬ 
tionship between two users defines an 
organizational domain. However, an 
administrator’s resource domain is 
defined as those resources to which the 
administrator has access rights. This is a 
practical policy, but not one we 
recommend. 

A number of possible policies relate to 
organizational domains: 

• In universal organizational domains, 
an access right to a resource in the giver’s 
resource domain can be given to anyone. 

• In flat organizational domains, indi¬ 
vidual users are placed into a single 
organizational domain administered by a 
security administrator. 

• In hierarchical domains, users are 
structured by a manager into subdomains 
reflecting departmental structure. 12 Com¬ 
plete subdomains are delegated to a secu¬ 
rity administrator. 

Corresponding policies can relate to 



Whether owners give 
out access rights or 
delegate this to 
security 

administrators is itself 
a security policy 
decision. 


universal, flat, and hierarchical resource 
domains. 

Explicit authorization of domain poli¬ 
cies and the domains of individual security 
administrators is a required part of effec¬ 
tive internal control, while precise descrip¬ 
tion of them is a prerequisite for a model 
of an access control system. 

People and positions. In many organi¬ 
zations, access policy applies not to 
individuals but rather to the positions they 
occupy within the organization. When 
someone moves to a different position, 
most of that person’s access rights should 
not travel with him or her, but be inherited 
by his or her successor. The reason for this 
is that policy is not normally expected to 
change with changes in personnel. There 
are, of course, many counterexamples to 
this, so the following general policy allows 
for exceptions: 

• As far as possible, access rules should 
refer to positions, not people. 

In practice, this policy has helped reduce 
routine work by minimizing the changes in 
rules needed when people change 
positions. 

Ownership of resources. Internal con¬ 
trol principles require that resource owner¬ 
ship be unique and derive from delegated 
authority down the management struc¬ 
ture. Just as budgets can be passed down 
an organization by delegation of 
authority, so too can ownership of 
resources such as data and distributed 
hardware. 

Access control policy needs to take into 
account how much freedom people should 
have in relation to the resources with which 
they work. For example, the possible 
policy statement 

• A user may grant another user any 


kind of access right to data he or she has 
created. 

might be appropriate for a project which 
is not at all sensitive, but totally inap¬ 
propriate for someone using end-user 
computing tools for development of a 
secret product. The stronger statement 

• A user may grant another user any 
kind of access rights and give-rights to data 
he or she has created, 
will be acceptable only to liberal regimes. 

Therefore, there may be limits to the 
extent to which ownership of resources 
such as data should be passed down an 
organization. Most organizations have 
managerial positions, usually defined by 
the possession of a budget. These may also 
be the level down to which resource owner¬ 
ship should be allowed. Liberal institu¬ 
tions may place no restrictions in some 
cases. 


A simulation model 

Need for formal modeling. The discus¬ 
sion of policies above makes it clear that 
their consequences can be quite compli¬ 
cated and, indeed, that the policies them¬ 
selves can be difficult to formulate in 
normal English. So, there is a natural 
incentive to formalize the way in which 
they are described. There are two main 
reasons for creating a formal model of 
access control policies: 

• The model provides a precise specifi¬ 
cation from which implementation can be 
carried out. 

• The model can be used to validate 
security policy by ensuring that its conse¬ 
quences will actually be those intended. 

We can use simulation to explore the 
consequences of possible access control 
policies. We can also use it to find security 
weaknesses in existing access control sys¬ 
tems while avoiding the need to handle 
unmanageable quantities of data. 

The approach used by Snyder 6 was to 
trace the possible flow of access permis¬ 
sions through the model access control sys¬ 
tem, in order to determine whether 
undesired consequences could follow. This 
was possible because his models were self- 
contained, with the giving of access bound 
to the access right itself. 

Although it is a step forward to decou¬ 
ple the giving of access from the access 
right, 11 if we take the delegation of 
authority for security administration out¬ 
side the formal model, we cannot ask ques¬ 
tions about how rights can flow within the 
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model. The model can no longer be used 
for simulation. 

What we need is a formal model for 
specifying the security policies of an 
organization. The model must incorporate 
the five components identified earlier, 
namely, users, resources, operations on 
resources, domains, and the authority 
structure of the organization. As a step 
towards formal modeling, below we give 
an outline of how we used a Prolog pro¬ 
gram to represent comparatively complex 
policies. The model can be used to query 
both delegation of authority and ability to 
access a resource. 

Indirect relations. We require some 
definitions to specify the hierarchical rela¬ 
tionships manage, administer, and con¬ 
tains between people and resources. 

A relation is 

Transitive if: if jc rel y and y rel z, 
then x rel z. 

Reflexive if: x rel x 

Consider: 

• A marketing director manages a sales 
manager and the sales manager manages 
a salesman. 

• A root file directory contains the mar¬ 
keting files directory and the marketing 
files directory contains the marketing files. 
If manage is transitive, then the marketing 
director manages the salesman. However, 
it is a good principle that everyone should 
know who they work for, and in this case 
the salesman’s immediate superior is the 
sales manager, not the marketing director. 
So, we may well decide (as a matter of 
policy) that manage should not be a tran¬ 
sitive relation. Similarly, if contains were 
transitive, then the root file directory 
would contain the marketing files, which 
is not strictly correct. 

It is useful for each hierarchical relation 
to have both indirect and direct versions, 
where the indirect version is transitive and 
the direct one is not. It would then be true 
that 

• The marketing director indirectly- 
manages the salesman. 

• The marketing director indirectly- 
manages the sales manager. 

• The sales manager indirectly-manages 
the salesman. 

But the only true statements for manage 
would be 

• The marketing director manages the 
sales manager. 

• The sales manager manages the 
salesman. 


I 

Simulation can be 
used to explore the 
consequences of 
possible access control 
policies. 


We need to be able to reflect the policy: 

• The marketing director delegates 
administration of everyone in his depart¬ 
ment (including himself) to the security 
administrator. 

This can be arranged simply by ensuring 
that indirectly-manages is a reflexive 
relation: 

• The marketing director indirectly- 
manages himself or herself. 

Then 

• The security administrator adminis¬ 
ters a position if the marketing director 
indirectly-manages that position. 

If indirectly-contains is also defined as a 
reflexive and transitive version of con¬ 
tains, then we can express the following 
policy without having to worry about the 
level of the directory: A user has access to 
a data file if he has access to a directory 
which indirectly-contains the file. 

Introduction to the simulation model. 

The examples below are extracted from a 
model written in Logic Programming 
Associates’ Micro-Prolog 13 and run on an 
IBM PC. At this stage, we have only 
modeled an imaginary installation. Prolog 
is a very suitable language for modeling 
access control because it enables us to for¬ 
mulate statements which directly express 
the questions we wish to ask, such as 

has-rightlpmon resource access-right) 

We found that the structure of the Pro¬ 
log program fell naturally into three parts, 
reflecting the policy levels identified in the 
introduction. 

• General policies about organization 
and resource authority which apply to 
all installations and define the 
interpretation of concepts such as 
manage, administer, and contain. 

• Specific policies which define the rela¬ 


tionship between the resources and 
people in the imaginary organization 
to which the model applies. These are 
relatively invariant in time. 

• Access rules define the state of affairs 
at a particular point in time—what 
files, positions, and people are known 
to the system, and what access rights 
they have. 

We made maximum use of parameteri¬ 
zation and generalization in the model, 
gaining flexibility at the expense of read¬ 
ability. Our examples here have been 
amended to make them easier to read. 
Also, to enhance readability, we used the 
convention that predicates are in italics, 
while variables are in lowercase and con¬ 
stants that bind them are in uppercase, 
such as “positionl” and “MARKETING 
DIRECTOR.” 

Note that all grants of access rights are 
reinterpreted and revalidated at the time of 
an access request. This clarifies the way in 
which an access decision is made and 
involves no loss of generality. It does, 
however, have implications for the perfor¬ 
mance of the model. A working large-scale 
simulation model would validate all grants 
of access on a once-only basis, updating 
the database as it did so. 

Access rights. The overall aim of the 
model is to define who has access rights, 
given certain policies and facts. Possession 
of a right allows a specific operation on the 
resource. The corresponding predicate is 
has-right. Most queries on the model will 
be of the form 

has-right(person data right) ? 
and the main policy statements are of the 
form 

has-right(person data right) if. 

Operations. This model, for simplicity 
of illustration, recognizes only one type of 
resource—data. There is a hierarchy of 
directories, with the operations being per¬ 
formed on data files. The possible opera¬ 
tions are R, W, C & D, standing for Read, 
Write, Create & Delete. In this model, 
Write access does not imply Read access, 
although the implication could be easily 
included. 

GIVE-R GIVE-W GIVE-C GIVE-D are 
the give-rights which correspond to R, W, 
C & D. The model has to be told specifi¬ 
cally how to associate access rights and 
give-rights. This is done by direct facts 
included in it: 

g/ves(GIVE-R R) 

g/ves(GIVE-W W) 
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g/ves(GIVE-C C) 
g/ves(GIVE-D D) 

People and positions. There is a general 
policy that access rights refer to positions, 
not people, but it is people who grant 
accesses and perform operations. The 
model has to be told how to relate people 
to their positions. For simplicity this has 
been done by direct insertion of facts in the 
model, although it would have been more 
realistic to show that this, too, is an oper¬ 
ation requiring authority: 
occupies (person position) 

Organizational authority. For the 

organizational domain the main concepts 
are manages and administers. A manager 
gains the authority to manage positions by 
being granted it by the ultimate authority, 
the board. A security administrator gains 
the authority to administer a group of peo¬ 
ple by being granted it by their manager 
(see Figure 1). 

The BOARD grants-management to a 
manager over a defined domain which he 
or she then manages: 
manages (manager position) if 
grants-management (BOARD manager 
position) 

The organizational domain of the direct 
relation manages is a flat domain, consist¬ 
ing only of the positions defined by explicit 
grants of management, which are inserted 
into the database as facts. 

Indirectly-manages is defined in terms 
of manages as follows: 


position 1 indirectly-manages position2 
if 

position 1 manages position2 

position 1 indirectly-manages position 1 
(i.e., reflexive) 

position 1 indirectly-manages position3 
if 

position 1 indirectly-manages 

position2 

and 

position2 indirectly-manages 

position3 (i.e., transitive) 
There is a corresponding definition of 
indirectly-contains in terms of contains. 

A manager grants-admin to a security 
administrator for some or all of the 
domain which the manager indirectly- 
manages. The use of a transitive and 
reflexive indirect relation permits a simple 
description for the organizational domain 
administered by a security administrator: 
administers (sec-admin-name domainl) 
if 

grants-admin (manager-name 

sec-admin-position domain2) 

and 

occupies (sec-admin-name 

sec-admin-position) 

and 

occupies (manager-name 

manager-position) 

and 

indirectly-manages (manager-position 
domain2) 
and 

indirectly-manages (domain2 

domainl) 


The security administrator can then 
administer the domain which has been 
granted to him by the manager. 

Resource authority. For the resource 
domain an analogous hierarchy defines the 
way in which a security administrator can 
control access rights to a resource. The 
main concepts are owns and has-give-right 
(see Figure 2). 

The BOARD grants-ownership to a 
resource owner over a defined domain 
such as a directory, which he then owns. 
The organizational domain of the direct 
relation owns is, like manages, a flat 
domain: 

owns (owner directory) if 
grants-ownership (BOARD owner 
directory) 

A manager grants-give-right to a secu¬ 
rity administrator for some or all of the 
domain which the manager indirectly- 
owns. The security administrator then has- 
give-right over the domain granted him or 
her by the manager: 

indirectly-owns (owner directoryl) if 
owns (owner directory2) and 
indirectly-contains (directory2 

directoryl) 

has-give-right (sec-admin-name 

directoryl right) 
if 

grants-give-right (owner-name 
sec-admin-position directory2 right) 
and 

occupies (sec-admin-name 

sec-admin-position) 

and 

occupies (owner owner-position) and 
indirectly-owns (owner-position 

directory2) 

and 

indirectly-contains (directory2 

directoryl) 

Access rights. Access rights are granted 
to a position, for a particular operation on 
a specified directory, by a security 
administrator: 

position-has-right (position directory 
right) 
if 

grants-right (sec-admin-name 

position directory right) 

and 

administers (sec-admin-name 

position) 

and 

has-give-right (sec-admin-name 

directory give-right) 

and 

gives (give-right right) 
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A person has the right to perform an 
operation on a data file if he or she 
occupies a position which has that right on 
a containing directory: 

has-right (person data-file right) if 
position-has-right (position directory 
right) 

and 

occupies (person position) and 
indirectly-con tains (directory 

data-file) 

Specific policies in the model. There is 
no hard-and-fast distinction between the 
specific policies in this section and the rules 
in the next section. We can expect the spe¬ 
cific policies here to remain unchanged 
while the organization has its present 
structure, but the security administrator 
will alter the rules in accordance with day- 
to-day needs. 



Figure 2. Resource authority. 


About the organization and data. The 
following lists facts about the organization 
and data. See also Figure 3 and Figure 4. 
grants-management (BOARD 

MARKETING-DIRECTOR 
SALES-MANAGER) 
grants-management (BOARD 

MARKETING-DIRECTOR 
DESPATCH-MANAGER) 
grants-management (BOARD 

DESPATCH-MANAGER 
ORDER- SUPERVISOR) 


grants-management (BOARD 

DESPATCH-MANAGER 
DESPATCH- SUPERVISOR) 
grants-management (BOARD 

DESPATCH-SUPERVISOR 
DESPATCH-CLERK) 
contains (COMPANY-DIRECTORY 
MARKETING-DIRECTORY) 
contains ( 


MARKETING-DIRECTORY 
SALES-DIRECTORY) 
contains ( 

MARKETING-DIRECTORY 
DESPATCH-DIRECTORY) 
contains (DESPATCH-DIRECTORY 
ORDER-FILE) 
contains (DESPATCH-DIRECTORY 
DELIVERY-FILE) 




BOARD 



Figure 3. Organizational structure in the model. 
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MARKETING-DIRECTORY 

| 


SALES-DIRECTORY 


DESPATCH-DIRECTORY 

I 


DELIVERY-FILE 


Figure 4. Structure of data used in the model. 


Delegating authority, 
grants-ownership (BOARD 

MARKETING-DIRECTOR 
MARKETING-DIRECTORY) 
grants-admin (CHARLES 

SECURITY-ADMIN 
MARKETING-DIRECTOR) 
The above rather inelegant statement 
expresses the marketing director (Charles) 
giving the security administrator adminis¬ 
tration rights for all positions in his depart¬ 
ment, including himself. 
grants-give-right (CHARLES 
SECURITY-ADMIN 
MARKETING-DIRECTORY 
GIVE-R) 

grants-give-right (CHARLES 
SECURITY-ADMIN 
MARKETING- DIRECTORY 
GIVE-W) 

grants-give-right (CHARLES 
SECURITY-ADMIN 
MARKETING- DIRECTORY 
GIVE-C) 

grants-give-right (CHARLES 
SECURITY-ADMIN 
MARKETING-DIRECTORY 
GIVE-D) 

The above grants succeed because Charles, 
the marketing director, owns the market¬ 
ing data. 

grants-give-right (KEN 

ACCOUNTING-DIRECTOR 
MARKETING- DIRECTORY 
GlVE-R) 


This last statement will have no effect 
because Ken, the security administrator, 
does not own the marketing data. He can 
give access rights, but not give rights. A 
different policy could, of course, be imple¬ 
mented. 

Rules and facts in the model. This set of 
sample rules and facts can be used to run 
the model. Both are quite volatile. The 
rules are access rules made by the security 
administrator. The facts are descriptions 
of the occupants of specific positions. 

Occupants of positions. The following 
lists the occupants of positions, as shown 
in Figure 3: 
occupies (ARTHUR 

ADMIN-DIRECTOR) 
occupies (BEATRICE 

ACCOUNTING-DIRECTOR) 
occupies (CHARLES 

MARKETING- DIRECTOR) 
occupies (EDWARD 

SALES-MANAGER) 
occupies (FIONA 

DESPATCH-MANAGER) 
occupies (GEORGE 

ORDER-SUPERVISOR) 
occupies (HELEN 

DESPATCH- SUPERVISOR) 
occupies (IAN DESPATCH-CLERK) 
occupies (JANE 

DESPATCH-CLERK) 
occupies (KEN SECURITY-ADMIN) 


Granting access rights. The following 
lists a series of access rights granted by 
Ken, the security administrator: 
grants-right (KEN 

DESPATCH- CLERK 
DESPATCH-DIRECTORY W) 
grants-right (KEN 

DESPATCH-CLERK 
DESPATCH-DIRECTORY R) 
grants-right (KEN 

ORDER-SUPERVISOR 
MARKETING-DIRECTORY R) 
The above grants succeed, because the 
positions are within Ken’s organizational 
domain and the data is within his resource 
domain. Alternatively, the attempted 
grant 

grants-right (KEN 

ADMIN-DIRECTOR 
MARKETING-DIRECTORY R) 
has no effect, because the administration 
director is not in Ken’s organizational 
domain. 

Sample give-right queries. 

has-give-right (KEN 
MARKETING-DIRECTORY W) ? Yes 
has-give-right (BEATRICE 
MARKET ING-DIRECTORY R) ? No 

Sample access-right queries. 
has-right (IAN 

DESPATCH-DIRECTORY R) ? Yes 
has-right (JANE ORDER-FILE W) ? 

Yes 
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has-right (GEORGE 

DELIVERY-FILE R) ? Yes 
has-right (ARTHUR 
MARKETING-DIRECTORY R) ? No 

W e have discussed the need for 
protection in commercial 
organizations, and the way 
control principles have met this need 
despite having evolved before computer 
systems came into use. The basis for these 
principles is the concept of authority and 
how it is delegated within an organization. 
One of the most important of the control 
principles, segregation of duties, can be 
applied directly to the administration of 
access control. It implies a distinction 
between having access rights and being 
allowed to pass them on (give-rights). 

The components of commercial policy 
are: 

• Users of the system. Although it is 
people who use the system, policy deci¬ 
sions are normally taken with respect to 
organizational positions. We therefore 
make a distinction between people and the 
positions they occupy. 

• Resources, which are the programs, 
services, or data accessed by users. 

• Operations which can be performed 
on a resource. Access control must be 
applied to individual operations rather 
than the resource as a whole. 

• Domains, which are the boundaries 
within which the policy applies. Two types 
of domain have been used: the organiza¬ 
tional domain for determining the people 
who a security administrator has authority 
to administer, and the resource domain for 
determining the resources to which he or 
she can allow access. The ability to specify 
and delegate authority over subdomains 
helps in specifying policy. 

•Authority, which is the legitimate 
power to implement policy. Authority is 
delegated from the top management of an 
organization and is bounded by the 
domains defined when it was delegated. 
Authority over people is bounded by 
organizational domains and authority 
over resources, by resource domains. 

It is feasible to express commercial secu¬ 
rity policy embodying all these concepts 
within a Prolog simulation model, which 
specifies: 

• General policies —the general rela¬ 
tionship between managers, resource 
owners, security administrators, and 
the organizational and resource 
domains. 

• Specific policies —the way in which a 


particular imaginary organization has 
decided to structure its domains in 
accordance with general policies. 

• Access rules —the day-to-day deci¬ 
sions of a security administrator 
implementing the organization’s 
policies. 

The advantages of the Prolog approach 
are that it gives an executable model which 
can be queried to discover the conse¬ 
quences of the policies modeled. The back¬ 
tracking used by Prolog means that we can 
analyze the reasons for particular results. 
Its main disadvantage is that writing in 
Prolog directly uses a very low level of 
specification. It is possible to validate spe¬ 
cific cases but not prove the security of 
general policies. To do this, we need a 
higher-level formal model. The use of the 
formal description language Z 14 is being 
explored. 

The model has dealt so far with a single 
system, a single physical domain, and a 
single source of authority—a compara¬ 
tively simple configuration which could in 
practice be dealt with manually. The real 
incentive for executable models is for dis¬ 
tributed and networked systems, with mul¬ 
tiple sources of authority spread across 
numerous locations. The complexity of the 
interactions between authority domains 
makes it impossible to manually keep track 
of the distribution of access rights. Our ini¬ 
tial work on the use of executable models 
has proved very promising for the valida¬ 
tion of access control in such systems. □ 
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STANDARDS 


Editor: Helen M. Wood, National Bureau of Standards, B154 Technology, Gaithersburg, MD 20899; (301) 975-3240 


A standard dictionary of computer terminology: Project 610 

Jane Radatz, Logicon, Inc. and 610 project leader 


Which of these terms do you know?: 
backplane bus, information hiding, 
Monte Carlo method, Gray code, 
descender, contour encoding, linked 
list, pixel, token ring, backtracking, 
trojan horse, left-linear grammar. 

All are terms used in the computing 
field. IEEE Computer Society Project 
610 is chartered to identify such terms, 
develop a consensus regarding their 
meanings, and publish a standard dic¬ 
tionary of this terminology. The 610 
working group is organized under the 
Standards Coordinating Committee of 
the Computer Society’s Standards 
Activities Board. 

The objective of the 610 effort is two¬ 
fold. One objective is to inform—that 
is, to provide a useful reference to those 
who come across computer-related ter¬ 
minology and want to know what the 
words mean. The second objective is to 
standardize terminology—that is, to be 
a forum for reaching agreement on 
terms and their meanings. This objec¬ 
tive has two aspects: 

• Reaching agreement on what term 
to apply to a given item or concept. In 
many instances a given item or concept 
has two or more different names. This 
duplicate naming results in confusion 
and in disagreements where none need 
exist. Project 610 is attempting to select 
a preferred term among such synonyms 
and to encourage the use of that term. 

• Reaching agreement on what each 
term means. Many terms mean differ¬ 
ent things to different people. A prime 
example is “firmware,” which means a 
type of software to some people, a type 
of hardware to others, and a combina¬ 
tion of the two to others. Project 610 is 
attempting to select a preferred defini¬ 
tion among conflicting definitions and 
to encourage that definition’s use. 

The benefits of such standardization are 
considerable. A clear, well understood 
vocabulary enables writers, speakers, 
researchers, committees, publications, 
and others to start from a common 
ground in expressing ideas and to com¬ 
municate effectively with one another. 


Planned products. The 610 working 
group has been chartered to produce 12 
subject-area glossaries plus an overall 
dictionary containing an estimated 
5000-6000 terms. The 12 glossaries con¬ 
tain terminology in the following areas, 
illustrated in Figure 1: 

610.1— mathematics of computing 

610.2— computer applications 

610.3— modeling and simulation 

610.4— image processing and pattern 
recognition 

610.5— data management 

610.6— computer graphics 

610.7— computer networking 

610.8— artificial intelligence 

610.9— computer security and privacy 

610.10— computer hardware 

610.11— theory of computation 

729 (610.12)—software engineering 

The overall dictionary will contain all 

of the terms in the individual glossaries. 
Selected terms will also be incorporated 
into ANSI/IEEE Std 100, the IEEE 
Dictionary of Electrical and Electronics 
Terms. 

Progress to date. The first two glos¬ 
saries have been completed, balloted, 
and published. They are known as: 

ANSI/IEEE Std 1084-1986: 
Mathematics of Computing Termi¬ 
nology 

ANSI/IEEE Std 610.2-1987: Com¬ 
puter Applications Terminology 

Std 1084 will be redesignated 
ANSI/IEEE Std 610.1-1986 upon 
republication. The schedule for the 
glossaries is shown in Figure 2. 

Key participants. The working group 
has approximately 200 members, most 
of whom serve as expert reviewers in 
particular subject areas. Current key 
participants are identified in the accom¬ 
panying sidebar, “Current leaders in 
IEEE Project 610.” The “mathematics 
of computing” area, which is complete, 
was headed by the late Gary Lindsay of 
Teledyne Brown Engineering. 

Dictionary development process. The 

process we follow in developing the dic¬ 


tionary has six basic steps, illustrated in 
Figure 3 and described in the following 
paragraphs. 

Term selection. Selection and refine¬ 
ment of terms is an ongoing process. 
Our sources of candidate terms include 
textbooks, journals, proceedings, and 
other dictionaries. The term list for 
each glossary continues to expand and 
contract throughout the glossary’s 
development. The challenge is to be 
complete and current without incor¬ 
porating terms not widely accepted or 
not ready for standardization. 

A question that we face on topics 
with a substantial history is what to do 
with older terms. How complete should 
we be on terminology related to Hollerith 
cards, for example? How many terms 
should we include having to do with 
outdated memory technologies? We try 
to achieve a balance that does not 
ignore old terms, but that emphasizes 
terms in current usage. 

Dividing up the work. How does a 
group go about defining a large number 
of terms? At first glance, it might seem 
natural to say, “You take A, B, C; you 
take D, E, F; and so on.” The problem 
with this approach is that terms have to 
be defined and reviewed in logical 
groupings in order to have consistent 
definitions. The person who defines 
“analog computer” should also define 
“digital computer” so that the contrast 
between the two is clearly drawn. The 
person who defines “file” should also 
define “logical file” so that the defini¬ 
tions will complement each other. 

To meet this need, we adopted an 
approach that subdivides each of the 12 
major subject areas into smaller logical 
groupings of 25 to 50 terms. We define 
and review terms in these groupings. 
This approach has proven highly suc¬ 
cessful. The sidebar “Areas addressed 
by 610 subgroups” identifies the cur¬ 
rent groupings in each subject area. 

Development of draft definitions. We 
develop definitions by drawing on our 
own knowledge and by looking in text- 
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books, journal articles, dictionaries, 
and whatever other sources we can find. 
To date, the working group has 
gathered a total of 185 computer- 
related glossaries and dictionaries, plus 
hundreds of nondictionary sources. We 
make it a point to find each term in 
multiple sources to achieve a balance of 
ideas. On the average, we look up each 
term in five sources. We then select the 
best definition or, more often, write a 
composite definition reflecting the best 
elements from several definitions or 
descriptions. In those cases where we 
quote a definition verbatim, we make 
note of the source(s) quoted. 

Refining definitions for consistency. 

It came as a big surprise to us that 
drafting the definitions is only about 20 
percent of the job. The bigger job 
comes after all of the terms have draft 
definitions. It consists of making the 


definitions work together. Consider the 
following definitions for “constant” 
and “variable”: 

• constant: a data item whose value 

does not change 

• variable: a quantity that can 

assume any of a given set 

of values 

Taken individually, each of these defi¬ 
nitions isn’t bad. Taken together, they 
don’t work very well. Why is a constant 
a “data item,” when a variable is a 
“quantity”? Why are the last parts of 
the two definitions not more parallel to 
emphasize the contrast? The definitions 
should start out using identical words 
and remain as parallel as possible so 
that the contrast comes across clearly. 
For example, 

• constant: a data item whose value 

cannot change 


• variable: a data item whose value 
can change 

The English language is full of syno¬ 
nyms and near-synonyms that make it 
possible to say the same thing in many 
different ways. A major challenge that 
the working group faces is to use consis¬ 
tent language throughout the dictionary 
so that the reader never falsely assumes 
that we chose two different words to 
mean two different things when in fact 
the terms we chose are simply 
synonyms. 

The key mechanism for achieving this 
consistency is our “divide and con¬ 
quer” approach, described above. By 
grouping each term with logically 
related terms, both the definer and the 
reviewer can ensure that related terms 
are defined consistently. Our coordina¬ 
tion and consistency subgroup, 
described below, also addresses this 
issue. 
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Figure 2. Planned schedule for Project'610 glossaries. 



Ballot 


Figure 3. The Project 610 process. 


Expert review. The working group 
has taken great pains to recruit subject- 
matter experts to review the definitions 
and tell us whether they are complete 
and correct. The members who do the 
defining may not be experts in a partic¬ 
ular field and may have to rely on read¬ 
ing textbooks and articles to prepare the 
definitions. We want to be sure that 
experts in each field agree with our 
work. Each set of definitions is sent out 
at least once, often two or more times, 
to experts for review. The definitions 
are then revised to incorporate any 
comments received. 

Coordination and consistency review. 
The final step for each set of definitions 
is a review by our coordination and 
consistency subgroup. This group is 
responsible for ensuring that all defini¬ 
tions follow our style guide and are con¬ 
sistent with one another. Any problems 
found are corrected before IEEE bal¬ 
loting. 

Special challenges. The dictionary 
effort faces some special challenges that 
make it interesting and unique. 

Breadth of scope. Most IEEE work¬ 
ing groups focus on one particular 
topic—how to write a software quality 
assurance plan, or what the pin assign¬ 
ments should be on a particular bus. 
Such working groups are composed of 
experts and interested parties in that 
particular field. Our scope includes the 
entire spectrum of computer-related 
topics. 


One of our special challenges has 
been to identify and recruit definers and 
reviewers who together offer expertise 
in all of these fields. To meet this chal¬ 
lenge, our membership chairman, Mary 
Yee, has made hundreds of telephone 
calls to universities and companies, 
written articles for computer-related 
publications, and prepared flyers for 
distribution at conferences. The success 
of our effort is largely due to her 
recruiting efforts. 

Size of the dictionary. Most IEEE 
standards are no more than 35 pages 
long. These standards typically take 
three years to develop. The computer 
dictionary will be approximately 400 
pages long. It is, in essence, twelve 
simultaneous efforts rolled into one. 
The logistics of such an effort are con¬ 
siderable. We try to keep all twelve 
areas moving forward at a steady pace, 
but some move quickly and others lan¬ 
guish for distressingly long periods. As 
on all projects, volunteers come and go, 
and have varying degrees of time, 
energy, and interest to contribute. 

The original plan called for the dic¬ 
tionary to be developed, balloted, and 
published as one entity. It soon became 
clear, however, that the rate of comple¬ 
tion of the different subject areas was 
going to differ dramatically—by years 
in some cases—and it was decided to 
ballot and publish the completed sub¬ 
ject areas as separate glossaries as we 
went along. This approach has two 
benefits. It is a great morale booster for 
the working group to see a glossary 
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published, and it provides the fruits of 
our work to interested parties. 

Issues in dictionary development. We 

have been continually surprised by the 
number and type of issues that arise in 
what would appear to be a straightfor¬ 
ward process. The paragraphs below 
provide a sample of the questions we 
have addressed. 

Who is our audience? In preparing 
the dictionary, should we assume the 
reader has detailed knowledge of com¬ 
puters, no knowledge of computers, 
some technical knowledge, no technical 
knowledge, or something in between? 
The answer is critical because it 
influences our selection of terms and 
the wording of our definitions. 

After much discussion, we decided 
that we are writing the dictionary for 
any person who will come across 
computer-related words in his or her 
reading, either on or off the job. That 
mental picture of our reader has led us 
to maintain a balance between the tech¬ 
nical precision needed by experts and 
the clarity needed by laymen. 

How should terms be organized? The 
answer to this question may seem 
obvious—the terms should of course be 
organized from A to Z. One of the 
basic issues that we faced at the begin¬ 
ning of our project, however, was a 
strong minority position that the dic¬ 
tionary should be organized by topic, 
with terms organized from A to Z under 
each topic. 

There is precedent for such an organi¬ 
zation. The Data Processing Vocabu¬ 
lary of the International Standards 
Organization (ISO) is organized in this 
manner. The argument for this arrange¬ 
ment is that it places terms in context 
and is more informative than an overall 
list. The disadvantage is that when you 
pick up the dictionary, you can’t just go 
to the term based on its spelling. You 
have to know what section the term is 
in, or look it up in an index in the back 
of the dictionary. 

After much debate, we decided that 
the glossaries and the overall dictionary 
would be more usable with an overall A 
to Z organization in each. We try to 
ensure that each definition depicts the 
context in which the term is used. 

Which alphabetization scheme should 
we use? Even the decision to order the 
terms from A to Z was not the end of 
the story. There are two different ways 
to alphabetize when a dictionary 
includes both words and phrases. Con¬ 
sider the terms “adding” and “add 
transaction.” Which would you put 


first? The two schools of thought here 
are whether or not to ignore the blank. 
If you ignore the blank, then “add 
transaction” is alphabetized as though 
it were “addtransaction” and it goes 
after “adding.” If you take the blank 
into account, then “add transaction” 
goes before “adding.” 

Corresponding questions arise on 
how to alphabetize hyphens and 
slashes. Does “line-end zone” go 
before or after “line filling”? Does 
“input/output” go before or after 
“inputs”? Various dictionaries take 
different stands on these questions. 

We decided to take blanks into 
account and to regard hyphens and 
slashes right after blanks in alphabetical 
order. This rule seemed to us to put the 
terms in the order that most readers 
would look for them. 

Should the dictionary be descriptive 
or prescriptive? Dictionary writers face 
the question “Should we tell it like it is 
or tell it like it should be?” The official 
terms for these choices are descriptive, 
meaning describing current usage, 
versus prescriptive, meaning prescribing 
how terms should be used. 

There are advantages and disadvan¬ 
tages to both approaches. To be com¬ 
pletely descriptive, we would need to 
seek out and reflect every way in which 
each term is used. This approach is 
informative, but seems to contradict the 
notion of developing a standard dic¬ 
tionary. To be completely prescriptive 
establishes a standard, but often ignores 
reality. 

An example of an area in which this 
issue arises is the terminology related to 
fault tolerance. Experts in fault toler¬ 
ance have carefully thought through the 
difference between a human mistake, 
the resulting fault in a computer pro¬ 
gram, and resulting failure when the 
program is run, and the amount by 
which the output is in error. Most peo¬ 
ple call each of these an error—“I made 
an error; my program contains an error; 
my program generated an error; the 
result is in error by five miles.” The 
fault tolerance folks, however, carefully 
distinguish between mistakes, faults, 
failures, and errors. 

The question for the dictionary proj¬ 
ect is whether to reflect the way most 
people talk about these concepts or to 
reflect the careful, but not widely used, 
terminology of the fault tolerance field. 
After much debate on this issue, we 
chose a middle ground. We are includ¬ 
ing in the dictionary the most common 
current usage(s) of each term and also, 
with explanations, prescribed but 
uncommon usages. 


Should abbreviations be included? 
We computer types use a lot of abbrevi¬ 
ations. The working group decided 
early in the project to include abbrevia¬ 
tions. The harder question was whether 
to intermix the abbreviations with the 
other terms or to present them in a sep¬ 
arate listing at the back of each 
glossary. 

The deciding factor was again usabil¬ 
ity. Several members pointed out that 
terms like Basic and Cobol are in fact 
abbreviations, but the reader might not 
know that and would look in the main 
dictionary, not in the abbreviation list. 
Furthermore, these terms have in some 
sense gone beyond being abbreviations 
and are terms in their own right. Once 
we saw that we could not clearly distin¬ 
guish between terms and abbreviations, 
we decided to make one overall list con¬ 
taining both types of entries. 

Should we include proprietary terms? 
A major source of debate has been 


Current leaders in 
IEEE Project 610 

The following list shows Project 610 
leaders’ names in bold, their affilia¬ 
tions in parentheses, and their 
specializations within the 610 group: 

Jane Radatz (Logicon, Inc.)—overall 
610 project, software engineering 

Anne Geraci (Burroughs Well¬ 
come)—computer applications, 
modeling and simulation, image 
processing and pattern recognition, 
data management 

John Lane (Edinboro University of 
Pennsylvania)—coordination and 
consistency 

Louise McMonegal (US Naval Facili¬ 
ties)—computer graphics 

Russell Mikel (HT Research Insti¬ 
tute)—artificial intelligence 

Larry Reeker(BDM Corp.)—theory of 
computation 

Charles Russell (Logicon, Inc.)— 
computer security and privacy 

Ernest Stalder (US Dept, of the 
Interior)—computer networking 

Michael Strait (University of Mary¬ 
land)—computer hardware 

Mary Yee (Logicon, Inc.)— 
membership and publicity 


February 1988 


75 




Areas addressed by 610 subgroups 


Computer hardware 

• networking hardware 

• 1C technology 

• computer architecture 

• analog computer hardware 

• mainframe hardware 

• digital logic components 

• microprocessors 

• microprogramming 

Software engineering 

• addressing 

• assembling, compiling, linking, 
loading 

• cohesion and coupling 

• computer performance 
evaluation 

• configuration management 

• data types 

• debugging 

• documentation techniques 

• documentation types 

• errors, faults, and failures 

• evaluation activities 

• formal reviews and audits 

• instruction formats 

• language types 

• libraries 

• microprogramming 

• module interaction 

• operating system concepts 

• exception/interrupt handling 

• job/supervisor concepts 

• job scheduling methods 

• resource management 

• path analysis and proof of cor¬ 
rectness 

• program statements/instruc¬ 
tions/operations 

• programming languages 

• quality attributes 

• requirement types 

• software and system testing 

• software architecture 

• software development process 

• software development tech¬ 
niques 

• software miscellaneous 

• software tools, utilities 

Mathematics of computing 

• arithmetic errors 

• basic math 

• Boolean algebra 

• complementation 

• computer arithmetic 

• error detection and correction 

• mathematical notation 

• number conversions 

• number systems 

• numeric codes 

• numerical analysis 

• punched card formats 

• shifts 

• statistics and probability 

Computer graphics 

• general 

• graphics hardware concepts 

• graphics equipment 


• graphics techniques 

• graphics attributes 

• graphics primitives 

• graphics inputs 

• 3D graphics 

Theory of computation 

• automata 

• Petri nets 

• computational complexity 

• Chomsky hierarchy 

• phrase structure grammars 

• formal languages 

• parsing 

• strings 

• models of computation 

• Turing machines 

• program logics 

• program semantics 

• computability 

• recursion 


Artificial intelligence 

• subareas of Al 

• graphs 

• rule-based programming 

• Al theory 

• logic 

• knowledge representation 

• expert systems 

• computer learning 

• natural language processing 

• Al programming languages 

• inference and control of 
reasoning 

• searching 

• robotics 

• computer vision 


Computer networking 

• networks 

• data communications 

• general communications 

• error conditions 

• protocols 

• signal processing 

• open systems architecture 

• local area networks 

• networking hardware 

• telephone networks 


Computer security and privacy 

• administrative issues 

• communications security 

• emanations 

• encryption 

• formal verification methods 

• general 

• threats 

• physical security 

• piracy 

• privacy 

• passwords 

• security assessment 

• security-related hardware 

• software measures 

• access concepts 

• types of security 


Data management 

• characters 

• data 

• attributes 

• data elements 

• fields 

• files 

• general 

• records 

• data dictionary 

• data structures 

• linear 

• nonlinear 

• trees 

• data types 

• database—general 

• keys 

• searching and searching 
algorithms 

• sorting 

• general 

• algorithms 

• data access methods 


Image processing and pattern recog¬ 
nition 

• pattern recognition 

• images 

• digital images 

• image processing techniques 


Modeling and simulation 

• types of models 

• types of simulations 

• simulation—general 

• game theory 

• queueing theory 

• variables 


Computer applications 

• automated language processing 

• automatic indexing 

• business data processing 

• CAD/CAM 

• character recognition 

• computer-assisted instruction 

• control systems 

• critical path method 

• library automation 

• medical applications 

• micrographics 

• miscellaneous 

• office automation 

• operations research 

• personal computing 

• robotics 

• scientific and engineering appli¬ 
cations 

• telecommunication applications 

• types of processing 

• user concepts 

• word processing 

• general 

• text editing 

• text formatting 
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whether to include terms like AT&T’s 
Unix and IBM’s SNA, which are widely 
used but are, in fact, product names. 
The argument in favor of including 
them is that people will run across them 
and look them up. The argument 
against them is that they are commercial 
products and, since we cannot possibly 
include all competing products, we 
should not include any. In this case, we 
decided in favor of caution over help¬ 
fulness. Proprietary terms will not be 
included. We still have mixed feelings 
about some of our favorite terms, but 
decided on the safer course. 

How much tutorial information 
should definitions include? Some of our 
members are uncomfortable limiting the 
entry for each term to a simple defini¬ 
tion. They advocate a more encyclopedia¬ 
like approach, with background and 
tutorial information provided for each 
term. We decided not to take this 
approach. Our selected format includes 
a definition, cross references to related 
terms, and, in some cases, examples and 
brief notes. We feel that we serve our 
readers best with this format. 

How to handle definitions from other 
sources? One of our key operating 
procedures is to keep careful track of 
sources and to give credit when we 
quote a definition verbatim. Questions 
began to arise right away, however, 
over this seemingly straightforward 
policy. The thing about definitions is 
that every word and every comma 
count. When we find a definition that 
we like, but want to delete one comma, 
are we still quoting the definition? How 
about when we change “the” to “a” or 
“which” to “that”? How about when 
we change “see ...” to “see also ...” 

On one hand, we want to be fair and 
give credit where credit is due. On the 
other hand, we aren’t sure how a source 
might feel if one of its definitions is 
changed, but we still credit the source as 
though it were quoted exactly. 

Our final decision was to keep track 
internally of whether a definition is 
quoted exactly, slightly adapted, or 
changed so much that it could no longer 
be considered quoted. In the final prod¬ 
uct, we cite the source only for defini¬ 
tions that we quote exactly. We believe 
that this is the fairest approach. 

Dare we disagree with other stan¬ 
dards? The other side of avoiding pla¬ 
giarism is deciding whether to cite, 
without question, definitions that 
appear in IEEE and other standards. 
After all, the argument goes, if the defi¬ 
nitions have already been standardized, 
who are we to alter the wording? 


This approach seems good in theory, 
but we soon found that definitions 
drawn from different sources have 
inconsistent styles, use words and con¬ 
cepts differently, disagree among them¬ 
selves, and become confusing and 
inappropriate when placed in a new 
context. To deal with this problem, we 
have adopted an approach of quoting 
standard definitions whenever possible, 
but maintaining the freedom to change 
the style and wording of these defini¬ 
tions if they are incompatible with 
others in the dictionary. 

Should we avoid quoting? The work¬ 
ing group has been advised not to quote 
any definition except those in existing 
IEEE standards, to avoid copyright 
problems. We balked at this advice. It 
seems to us that if our overall goal is to 
promote standardization, then to 
change a perfectly good definition is 
counterproductive. So, while fewer than 
10 percent of our definitions have ended 
up being direct quotes, we have reserved 
the right to quote other sources, cite 
these sources, and obtain copyright per¬ 
mission when we wished to use a defini¬ 
tion verbatim. 

Should we write in American or Brit¬ 
ish English? The IEEE is an interna¬ 
tional organization. While we are not 
equipped to define the terms in the lan¬ 
guages of all countries having IEEE 
membership, we wanted at the least not 
to exhibit American parochialism. To 
this end, we took pains to recruit 
reviewers from Canada, Great Britain, 
and other English-speaking countries 
and to reflect alternate spellings (such 
as center and centre) and usage in the 
dictionary. 

How does our effort relate to a simi¬ 
lar effort by X3K5? Accredited Stan¬ 
dards Committee X3K5 is charged with 
developing and updating a dictionary of 
information processing terminology 
that somewhat overlaps the scope of 
Project 610. X3K5 published the 
American National Dictionary of Infor¬ 
mation Processing (ANDIP) in 1977 
and an updated version called the 
American National Dictionary of Infor¬ 
mation Processing Systems (ANDIPS) 
in 1982. It is currently working on an 
update to ANDIPS. 

An ongoing issue is how our two 
groups can best cooperate. To promote 
this cooperation while striving to serve 
our somewhat diverse constituencies, 
project 610 uses ANDIPS as one of its 
sources, encourages X3K5 to use 610 as 
one of its sources, and welcomes the 
continued participation of a liaison rep¬ 
resentative from X3K5. 


Looking ahead. 610 is an interesting 
and challenging project. Those of us 
involved have become close friends with 
large vocabularies. The end is still a 
long way off, but our progress is steady 
and we are determined to complete the 
job. 

Our work will never be completely 
finished, however. By the time we pub¬ 
lish the entire dictionary, it will be time 
to start revising. We try not to think 
about that too much. 

Volunteers are always welcome. We 
need definers and reviewers, both for 
the subject matter areas and for the 
coordination and consistency subgroup. 
If you would like to contribute in any 
of these ways, please contact our mem¬ 
bership chair, Mary Yee, at (202) 
646-2222. 

Finally, I would like to thank our 
former and current sponsors in the 
Computer Society, Herb Hecht, 

Fletcher Buckley, Laurel Kaleda, and 
Helen Wood; our advisor from the 
IEEE Standards Office, Frank Jay; our 
IEEE editors, Judy Gorman and San¬ 
dra Valentin; those who have sent us 
dictionaries and good wishes; and all 
members of the 610 working group. 
These individuals have offered support, 
encouragement, and help to our proj¬ 
ect. We are grateful to each of them. 


UNIVERSITY OF MISSOURI-COLUMBIA 
Chairperson 

Applications are invited for the position 
of Chairperson, Department of Electri¬ 
cal and Computer Engineering, Univer¬ 
sity of Missouri-Columbia. An applicant 
must have demonstrated leadership 
ability in securing and performing 
funded research and in teaching and 
curriculum development. An earned 
doctorate is required. 

Electrical Engineering at UMC is the 
oldest EE department in the country 
and has 33 full-time faculty, 900 under¬ 
graduate and 200 graduate students. 
The department has active research 
programs in solid state, computer vi¬ 
sion and power electonics. Under new 
leadership the College is making a ma¬ 
jor commitment to revitalizing re¬ 
search. UMC is a broad-based universi¬ 
ty with significant opportunity for inter¬ 
disciplinary research. 

Full consideration will be given to ap¬ 
plications received by April 15, 1988; 
however, applications will be con¬ 
sidered until the position is filled. The 
University of Missouri is an equal op¬ 
portunity affirmative action employer. 
Respond with complete resume and 
list of references to: 

Professor E. J. Charlson 
Chairman, Search Committee 
Department of Electrical and 
Computer Engineering 
University of Missouri-Columbia 
Columbia, MO 65211 
314/882-3559 
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CALL FOR PAPERS 

9th Real-Time 
Systems Symposium 



December 6-8,1988 
Huntsville, Alabama 

T he Symposium will explore the theory and techniques for designing real-time systems. Of particular interest are case 
studies on the control of parallel and distributed processors, sensors, and output devices to meet real-time constraints. 

Both formal and panel discussion sessions are planned. Papers and panels are solicited in areas related to the theory, design, 
implementation, and evaluation of real-time systems including, but not limited, to the topics above. 

SYMPOSIUM COMMITTEE 
General Chairman 

Dr. Walter L. Heimerdinger 
Honeywell Inc. 

Systems & Research Center 
MN65-2100 
3660 Technology Drive 
Minneapolis, MN 55418 
(612) 782-7319 

ARPANET: Heimerdinger@ HI-MULTICS 


PAPER SUBMISSION REQUIREMENTS 

Four copies of papers should be sent by May 1,1988 to the Program Chairman. Authors will be notified of acceptance by 
July 15, 1988. Camera ready copy will be required on IEEE mats by September 1,1988. Outstanding papers will be 
considered for publication in the journals of the IEEE Computer Society. For more information, contact the General Chairman. 

SYMPOSIUM TIMETABLE: Four Copies of Manuscript 
Acceptance Letters 
Camera-Ready Papers 
Symposium 


May 1,1988 
July 15,1988 
September 1,1988 
December 6-8,1988 


► THE INSTITUTE OF ELECTRICAL 
AND ELECTRONICS 


Program Chairman 

Prof. Al K. Mok 

Dept, of Computer Science 

TAY 3-HOC 

University of Texas at Austin 
Austin, TX 78712 
(512) 471-9542 

ARPANET mok@sally. utexas. edu 

Treasurer 

Dr. Earl Swartzlander, Jr. 

TRW, Redondo Beach, CA 


Sponsoring Technical Committees 

Real-Time Systems 

Distributed Computing Systems 

Operating Systems 

Data Base Systems 

Fault Tolerant Computing 

Software Engineering 

Local Arrangements 

Dr. William C. McDonald 

UNISYS 

Huntsville, AL 

(205) 837-7610 
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C °X5 NEWS 


Editor Sallie Sheppard, Office of Associate Provost for Honors Program and Undergraduate Studies, Texas A&M University, College Station, TX 77843; (409) 845-3210 


Computer Society calls for Board of Governors 
nominees, sets down 1988 election timetable 


The Nominations Committee of the 
Computer Society is inviting sugges¬ 
tions from the membership for CS 
Board of Governors nominees to serve 
terms starting January 1, 1989. 

Since 1989 will begin a period of tran¬ 
sition from standard two-year terms to 
standard three-year terms, 14 board 
seats will be filled this year only during 
the fall membership election. The seven 
candidates receiving the highest number 
of votes will be elected to three-years 
terms in office, while the seven candi¬ 
dates receiving the next highest number 
of votes will be elected to two-year 
terms. 

Amendments to the society’s consti¬ 
tution in 1987 increased the number of 
Board of Governors members from 20 
to 21; increased board terms from two 
years to three years; and decreased the 
number of board members elected each 
year from 10 to seven. Therefore, start¬ 
ing with the elections in 1989, seven new 
board members will be elected each year 
to three-year terms. 

Nominations Committee Chair Roy 
Russo must receive suggestions for 
Board of Governors nominees by 
March 18, 1988. The suggestions must 
be accompanied by biographical infor¬ 
mation and should include facts about 
the nominee’s past or present participa¬ 
tion in the society’s activities. Russo’s 
address is IBM T.J. Watson Research 
Center, Route 134, PO Box 218, York- 
town Heights, NY 10598. 

Also in this year’s election, the mem¬ 
bership will select first and second vice 
presidents, who will each serve in 1989, 
as well as the person who will be the 
president-elect in 1989, president in 
1990, and past president in 1991. 

Election timetable. The following 
timetable for nominations and elections 
(for events following the committee’s 
March 18 nominations deadline) was 


approved by the Board of Governors at 
its October 30, 1987 meeting: 

April 8—Nominations Committee 
sends its report to the Board of Governors. 

April 29—Final date for receipt of 
petitions by the society’s secretary, 
Duncan H. Lawrie, signed by members 
of the 1988 Board of Governors for 
additional nominees for the board and 
for officers. 

June 17—Candidates for the board 
and officers selected at Board of Gover¬ 
nors meeting. 

July —Computer lists the slate of can¬ 
didates selected by the board and calls 
for additional petition candidates from 
the membership. (The process allowing 
members to nominate additional candi¬ 
dates by petition is described below.) 

July 8—Position statements, biogra¬ 
phies, and photos of the candidates 
selected by the Board of Governors due 
at the society’s Los Alamitos office. 

August 1—Petitions with candidates’ 
position statements, biographies, and 
photos due at the office of the society’s 
secretary, Duncan H. Lawrie, Univer¬ 
sity of Illinois, 305 Talbot Laboratory, 
104 South Wright Street, Urbana, IL 
61801. 

September —Computer carries the 
position statements, biographies, and 
photos of the candidates. 

September 2—Ballots are mailed to 
the membership. 

October 14—Last day for receipt of 
marked ballots. 

December —Computer publishes the 
election results. 

Petitioning nominations. Petitions to 
add nominees to the list of candidates 
previously selected by the Board of 
Governors for the board or for officers 
shall: 

• set forth the office, the starting 
date of the office, and the name of 
the candidate. 


• contain, for board nominees, the 
signatures of at least 50 voting 
members of the society, with each 
member eligible to sign only one 
Board of Governors’ petition and, 
for officer nominees, the signatures 
of at least 250 voting members of 
the society, with each member eligi¬ 
ble to sign one petition for each 
office. Each signature shall be 
accompanied by the printed name 
of the signer. To avoid ambiguous 
identification of each signer, it is 
recommended (although not 
required) that the signer’s member¬ 
ship number accompany his or her 
signature. 

• be accompanied by a statement 
signed by the nominee that he or 
she is willing and available to serve, 
if elected. 

• be received by Secretary Lawrie on 
or before August 1, 1988. 

To qualify as a candidate for the 
board, a nominee must be a member of 
the society, must agree to seek signifi¬ 
cant involvement in society activities 
such as chairing a committee or serving 
as editor-in-chief or society representa¬ 
tive, etc., and must meet other require¬ 
ments as stated in the constitution and 
bylaws. 

To qualify as a candidate for an offi¬ 
cer position, a nominee must hold a 
member grade or higher in the IEEE, 
must have been a Computer Society 
member for the preceding three years, 
and must meet other requirements as 
stated in the constitution and bylaws. 

Petitions may also be submitted by 
Compmail + to the secretary. To be 
counted as a signature on a 
Compmail + petition, each person sign¬ 
ing the petition by Compmail + must 
originate a message stating his/her sup¬ 
port of the nomination of the individual 
concerned and transmit it to Lawrie. 

His Compmail + ID is d.lawrie. 
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IEEE formulates new approach for 
advancement of members to fellow grade 


The IEEE has formulated a new 
approach to recognize outstanding sen¬ 
ior members for elevation to the fellow 
grade. According to Jack Hilibrand, 
chair of the IEEE Fellow Committee, 
the move will permit more members 
who work in industry to attain fellow 
status than was previously possible. 

The new criteria call for greater 
recognition of “contributions in prod¬ 
uct design and applications, and the 
construction, operation, and evolution 
into practical use or manufacturing of 
products or systems,” Hilibrand said. 

The intent of the institute’s new 
approach is to increase recognition of 
professionals not in a position to pub¬ 
lish their work for proprietary reasons. 
Hilibrand said it also focuses attention 
on engineers in industry at a time when 
industrial competitiveness hinges on 
their expertise in turning out high- 
quality, useful, and cost-competitive 
products and services. 

With the new criteria, documentation 
of the candidate’s achievements can 
now be culled from employers’ internal 
technical literature, instruction manuals, 
specifications, and colleagues’ tes¬ 
timonials. Disclosure of the product’s 
makeup and the individual’s specific 
technical contributions to it will still be 
necessary, said Hilibrand. 

He stressed that the new emphasis on 
practical applications in nominating 
IEEE fellows will not eclipse the recog¬ 
nition extended to members for their 
theoretical or scientific findings. The 
new criteria go into effect this year. 

Seeking nominees. Nominations of 
Computer Society members for 
advancement to fellow are now being 
sought by the CS Fellows Committee. 

Kits containing the 1988 nomination 
forms may be obtained from either the 
Membership Department in the soci¬ 
ety’s West Coast office, 10662 Los 
Vaqueros Circle, Los Alamitos, CA 
90720-2578; (714) 821-8380, or from 
Dolores Wright at IEEE headquarters, 
345 East 47th St., New York, NY 
10017-2394; (212) 705-7750. 

Early preparation of the forms is 
recommended since it takes time to 
carefully complete the documents and 
collect the necessary references. 

Tilak Agerwala of IBM, this year’s 
CS Fellows Committee chair, will give 
advice on completing nomination 
forms. He can be reached at IBM, Old 
Orchard Rd. Armonk, NY 10504; (914) 
765-6491. 

The deadline for submission of the 


forms to IEEE headquarters at 345 East 
47th St., New York, NY 10017-2394, is 
April 30, 1988. 

Others must nominate. Fellow is the 
highest grade of membership and the 
only level for which members cannot 
personally apply but must be nominated 
by another member, Agerwala said. 

“The election to IEEE fellow grade is 
a distinct individual honor conferred as 
recognition of outstanding contribu¬ 
tions to our profession,” he said. 

Agerwala indicated that the society 
has been able to increase the number of 
its members elected to fellow in recent 
years, but that the percentages are still 
below the society’s proportion of mem¬ 
bers in the IEEE. 

“Therefore, I urge you to nominate 
qualified Computer Society candidates 
for election to fellow grade. Undoubt¬ 
edly, there are many deserving mem¬ 
bers. It is up to our members, whether 
they are fellows or not, to take on the 
task of identifying worthy candidates, 
completing the necessary paperwork, 
and meeting the deadline for submittal 
of the nominations,” Agerwala said. 

In evaluating the nominations, the 
IEEE Fellow Committee considers the 
following criteria: 

• individual contributions as 
engineer/scientist/originator, tech¬ 
nical leader, or educator; 

• evaluation by an IEEE society; 

• tangible and verifiable evidence of 
technical accomplishment, such as 
technical publications, patents, 
reports, or published descriptions 
of products, facilities, and/or ser¬ 
vices performed; 

• confidential opinions of IEEE fel¬ 
lows qualified to judge the work of 
the candidate (where possible, these 
should be associated with other 
than the candidate’s own organi¬ 
zation); 

• service to IEEE (AIEE/IRE) and 
other professional engineering soci¬ 
eties; and 

• total years in the profession. 

Eligibility requirements also include 
five years’ membership and status as a 
senior member, a grade awarded on the 
basis of an application prepared by the 
member. Applications for senior mem¬ 
bership may be obtained by circling No. 
204 on the Reader Service Card at the 
back of this issue of Computer. 


The IEEE Fellow Committee has 
conferred the title of fellow on 52 
more Computer Society members. 

Of the 361 IEEE senior members 
nominated, 200 were elected to fel¬ 
low grade as of January 1, 1988. 

The title of fellow recognizes the 
outstanding contributions of senior 
IEEE members in one or more areas. 
The following alphabetically lists the 
new IEEE fellows in the Computer 
Society. The group, council, or soci¬ 
ety that elevated the respective can¬ 
didate appears in parentheses. 

Shakir A. Abbas, Wappingers Falls, 

N.Y., for contributions to characteriza¬ 
tion and analysis of field effect transis¬ 
tors (Electron Devices) 

Alfred V. Aho, Murray Hill, N.J., for 
contributions to programming language 
translation, to data structures and 
algorithms, and to data systems 
(Computer) 

Saul Amarel, New Brunswick, N.J., for 
contributions to problems of representa¬ 
tion in artificial intelligence (Computer) 

Thomas P. Barnwell III, Atlanta, Ga., 
for contributions to algorithms for digital 
coding of speech signals (Acoustics, 
Speech, and Signal Processing) 

Laszlo A. Belady, Austin, Texas, for 
contributions to the design of large soft¬ 
ware systems (Computer) 

P. Bruce Berra, Syracuse, N.Y., for con¬ 
tributions to database machines 
(Computer) 

Jon G. Bredeson, Norman, Okla., for 
contributions to switching theory and 
error-correcting codes (Computer) 

A. Bertrand Brill, Worcester, Mass., for 
contributions to the use of radiation in 
medicine (Nuclear and Plasma Sciences) 

John P. Burg, Cupertino, Calif., for dis¬ 
covery of maximum entropy spectral 
analysis (Acoustics, Speech, and Signal 
Processing) 

Ralph K. Cavin III, Research Triangle 
Park, N.C., for technical contributions 
in systems and signal processing (Circuits 
and Systems) 

Vinton G. Cerf, Annandale, Va., for 
contributions and leadership in the 
design, development, and application of 
internet protocols (Communications) 

Chi-Hau Chen, North Dartmouth, 

Mass., for contributions to statistical pat¬ 
tern recognition and its application to 
geophysical, underwater acoustics, and 
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52 CS members elected to prestigious fellow grade 


ultrasonic nondestructive evaluations 
(Systems, Man, and Cybernetics) 

Peter Pin-Shan Chen, Baton Rouge, La., 
for origination and application of the 
entity-relationship model in database 
engineering (Computer) 

George E. Cook, Brentwood, Tenn., for 
contributions to industrial automation 
and electric arc welding (Industry Appli¬ 
cations) 

Russell C. Drew, Sterling Park, Va., for 
technical leadership in the development 
of process control and chemical analysis 
instrumentation systems (Industry Appli¬ 
cations) 

Mohamed I. Elmasry, Waterloo, Ont., 
Canada, for contributions to the field of 
digital integrated circuits (Solid-State 
Circuits) 

Patrick P. Easang, Santa Clara, Calif., 
for contributions to improved testability 
of very large scale integrated circuit 
designs (Industrial Electronics) 

Takeshi Fukao, Tokyo, Japan, for con¬ 
tributions to the methodology of power 
system analysis, control, and operation 
(Power Engineering) 

Paul K. Giloth, Wheaton, Ill., for techni¬ 
cal leadership in the development of toll 
digital switching systems (Communi¬ 
cations) 

Robert M. Glorioso, Stow, Mass., for 
leadership in the development of high- 
performance minicomputers (Computer) 

David J. Goodman, Holmdel, N.J., for 
contributions to robust quantization and 
variable rate coding (Communications) 

James F. Greenleaf, Rochester, Minn., 
for contributions to the development of 
advanced medical imaging (Ultrasonics, 
Ferroelectrics, and Frequency Control) 

John M. Flarker, Palo Alto, Calif., for 
leadership in the development of infor¬ 
mation storage devices (Magnetics) 

Tadao Ichikawa, Higashi-Hiroshima, 
Japan, for contributions to semantic 
databases (Computer) 

Anil K. Jain, Davis, Calif., for contribu¬ 
tions to image processing (Acoustics, 
Speech, and Signal Processing) 

Edwin C. Jones, Jr., Ames, Iowa, for 
contributions to engineering education 
(Education) 

Sun-Yuan Rung, Princeton, N.J., for 
contributions to very large scale inte¬ 
grated arrays for signal processing 


(Acoustics, Speech, and Signal 
Processing) 

Raymond S. Larsen, Menlo Park, Calif., 
for contributions to advances in high¬ 
speed analog sampled data devices, cir¬ 
cuits, and large-scale systems, and for 
leadership in the development of high¬ 
speed data bus standards (Nuclear and 
Plasma Sciences) 

Stephen S. Lavenberg, Yorktown 
Heights, N.Y., for contributions to the 
theory and practice of computer perfor¬ 
mance modeling (Computer) 

Stefano Levialdi, Rome, Italy, for contri¬ 
butions in developing, designing, and 
coordinating the construction of a 
pyramidal multiprocessor architecture for 
parallel image processing (Computer) 

Martin D. Levine, Montreal, Que., 
Canada, for contributions and leadership 
in computer vision (Computer) 

Gabriele Maschio, Milano, Italy, for con¬ 
tributions to the development of high- 
voltage dc power cables (Power 
Engineering) 

Premachandran R. Menon, Amherst, 
Mass., for contributions to methods of 
simulation and testing of digital circuits, 
and to switching theory (Computer) 

M. Granger Morgan II, Pittsburgh, Pa., 
for leadership and pioneering contribu¬ 
tions to research and teaching in applying 
engineering to the areas of technology 
and public policy (Systems, Man, and 
Cybernetics) 

A. Richard Newton, Berkeley, Calif., for 
contributions to computer-aided design 
and simulation of integrated circuits (Cir¬ 
cuits and Systems) 

Stig L. Nilsson, Cupertino, Calif., for 
contributions to the development of digi¬ 
tal relaying and the control of ac and dc 
power systems (Power Engineering) 

Henry W. Ott, Livingston, N.J., for con¬ 
tributions to education in electromagnetic 
compatibility and to the development of 
design techniques for electromagnetic 
compatibility (Electromagnetic Compati¬ 
bility) 

Louis-Francois Pau, Lyngby, Denmark, 
for contributions to failure diagnosis and 
inspection techniques, knowledge-base 
pattern classification hardware, and the 
extension of game theory to numerical 
techniques in economic modeling 
(Computer) 

Abraham Peled, Scarsdale, N.Y., for 
contributions to the development of 
special-purpose digital signal processors 


(Acoustics, Speech, and Signal 
Processing) 

Gerald R. Peterson, Tucson, Ariz., for 
contributions to education in digital sys¬ 
tems and computers (Education) 

Dhiraj K. Pradhan, Amherst, Mass., for 
contributions to techniques and theory of 
designing fault-tolerant circuits and sys¬ 
tems (Computer) 

Guy Rabbat, Fort Lauderdale, Fla., for 
leadership and contributions to very large 
scale integration technologies (Computer) 

John A. Reagan. Tucson, Ariz., for 
accomplishments in lidar and solar radio- 
metric atmospheric sensing, and for con¬ 
tributions to electrical engineering 
education (Geoscience and Remote 
Sensing) 

Martin Reiser, Hirzel, Switzerland, for 
contributions to queueing network theory 
and performance modeling of computer 
communication networks (Communi¬ 
cations) 

Sartaj K. Sahni, Minneapolis, Minn., for 
contributions to computer algorithms, 
computer-aided design, and large-scale 
systems (Computer) 

Howard R. Schlossberg, Annandale, Va., 
for technical leadership and for identify¬ 
ing and encouraging key areas of research 
in quantum electronics (Lasers and 
Electro-Optics) 

Earl E. Swartzlander, Jr., Redondo 
Beach, Calif., for contributions to very 
large scale integration design of special¬ 
ized signal processors (Computer) 

Paul M.E.M. Van der Grinten, Heerlen, 
The Netherlands, for contributions to 
control engineering applications 
(Engineering Management) 

Anastasios N. Venetsanopoulos, 

Toronto, Ont., Canada, for contribu¬ 
tions to digital signal and image process¬ 
ing (Circuits and Systems) 

John F. Walkup, Lubbock, Texas, for 
contributions to digital image and optical 
signal processing (Computer) 

Tzay Y. Young, Coral Gables, Fla., for 
contributions to pattern recognition and 
image understanding of very large scale 
integration architecture for image 
processing (Computer) 

Steven W. Zucker, Montreal, Que., 
Canada, for contributions in computer 
vision and image processing (Computer) 
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Trio of topics discussed at Simulation TC’s annual meeting 

Sallie Sheppard, Texas A&M University 


Three activity areas dominated the 
agenda when the society’s Technical 
Committee on Simulation held its 
annual meeting in conjunction with the 
ACM Special Interest Group on Simu¬ 
lation (Sigsim). The session was con¬ 
ducted December 15 during the Winter 
Simulation Conference in Atlanta. 

Of prime interest at the meeting was 
formation of a standards working 
group in simulation terminology, joint 
publication of a newsletter between the 
TC and SIG, and last August’s jointly 
sponsored Conference on the Simula¬ 
tion of Computer Networks. 

A proposal has been submitted to the 
IEEE Standards office entitled “Stan¬ 
dard Method of Establishing the Func¬ 
tional Components of a Simulation 


Language.” (See p. 84 of the December 
1987 issue of Computer.) Preliminary 
interest in this subject is high, and 
several people have volunteered to serve 
on a working group. 

A meeting will be held in San Fran¬ 
cisco March 1 in conjunction with 
Compcon Spring 88 to further plan the 
activities of the group. For additional 
information, contact Oryal Tanir, Bell 
Canada, 2265 Roland Therrien, Lon- 
gueuil, Quebec, Canada J4N 1C5; tele¬ 
phone (514) 468-5524. 

Sigsim Chair Stephen Roberts sug¬ 
gested the TC and SIG jointly publish a 
newsletter, since the interests of the two 
groups are so closely related. A sub¬ 
committee was appointed to explore the 


possibilities. TC Chair Heimo Adels- 
berger distributed copies of the TC’s 
recently published newsletter, Model¬ 
ing. The position of newsletter editor is 
currently vacant. 

A short report was given on the 
IEEE/ACM Simulation of Computer 
Networks Symposium, attended by 
about 100 persons. 

Suggested topics for a second joint 
workshop, planned for the summer of 
1989, may be sent to Adelsberger at the 
Vienna Business School, Augusse 2, 

A-1090 Vienna, Austria. 

A report on the technical meetings 
conducted during the Winter Simula¬ 
tion Conference appears on the Confer¬ 
ences pages of this issue of Computer. 


Committee on Public Policy to follow and report on global change program 

Ned Kornfield, Widener University and COPP Chair 


At its 1987 summer meeting, the 
Committee on Public Policy reviewed 
the proposed international program on 
global change planned by the Earth 
Sciences Committee of the NASA Advi¬ 
sory Council in Washington, DC. 

COPP passed a motion endorsing the 
concept of having the Computer Soci¬ 
ety’s Technical Activities Board inves¬ 
tigate the ways in which the CS 
technical committees can participate in 
the program. COPP would periodically 
publicize the status and findings in its 
proposed newsletter and its other 
outlets. 

The voting members present agreed 
that all people, especially those with 
technologically advanced educations, 
face a new responsibility for our global 
future. Through economic and techno¬ 
logical activity, mankind has con¬ 
tributed to significant global changes 
within the span of a few generations. 

We have become part of the earth sys¬ 
tem and one of the forces for earth 
change. 

Research holds the key to knowledge 
of our global future. Studies of the 
earth’s components over the past 30 
years have revealed an unexpectedly 
complex and dynamic world. Recent 
research has also delineated the fun¬ 
damental interactions among those 
components and their profound effects 
on earth history and evolution. With 
new scientific insight and technology, 
we can gain a deeper understanding of 
the earth as a system and the conse¬ 


quences of global change on humanity. 

Understanding of the earth system is 
based on earth sciences and has tradi¬ 
tionally advanced through studies of 
individual components: the atmosphere, 
the oceans and ice cover, the biosphere, 
the crust, and the interior. Modern 
research is clarifying the dynamic inter¬ 
actions that connect these components 
and bind them into an integrated earth 
system. Global observations, new space 
technology, and quantitative models 
have enabled science to probe the com¬ 
plex, interactive processes of earth evo¬ 
lution and global change. 

Examples of global change include 
volcanic eruptions, African vegetation, 
ocean color, arctic ice distribution, sur¬ 
face winds, and the ozone layer. 

Volcanic eruptions recycle material 
from the earth’s interior to the atmos¬ 
phere and onto the surface of the 
planet. The most immediate effect of 
these eruptions has been changes they 
cause in temperature distribution. The 
influence of these changes on the Afri¬ 
can climate, together with human 
activity, impact desert expansion. 

Arctic ice distribution also helps 
regulate climate by reducing heat 
exchange between air and sea. Surface 
winds drive ocean currents and respond 
to ocean temperature changes. Ocean 
color changes influence the amount of 
heat the water can absorb and provide 
data on marine organism distribution. 
The ozone layer is said to be shaped by 


global atmospheric circulation, man¬ 
made chemicals, and so forth. 

The NASA report proposes global 
measurements, documentation of global 
change, the creation of an information 
base, and prediction. It urges the estab¬ 
lishment of the worldwide observation 
sources necessary to understand the 
physical, chemical, and biological 
processes responsible for earth evolu¬ 
tion. Just as weather statistics are cur¬ 
rently documented, these additional 
observations should be documented and 
the information assembled into accessi¬ 
ble databases so that they can be stud¬ 
ied and modeled to anticipate future 
global trends. 

COPP can participate in this effort 
by calling attention to the need to 
implement US and international pro¬ 
grams to provide the required observa¬ 
tions. The membership of the 
Computer Society can participate by 
urging the development of advanced 
information systems to process global 
data, facilitate its analysis, and generate 
quantitative models of the earth system 
so science can develop the capability to 
predict the changes that will likely occur 
in the near future. 

You are invited to participate in this 
effort as well as other COPP activities. 
To volunteer, please send your name 
and address to: Paul Davis, Secretary, 
Computer Society Committee on Public 
Policy, 41 West Huron Street, Jackson, 
OH 45640. 
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For TAB, 1988 marks second year in 1990s technology planning cycle 


Ken Anderson, Siemens Research & Technology and TAB Chair 


For the Technical Activities Board, 
1988 is the second of three years in a 
cycle called “Planning for the Technol¬ 
ogy of the 1990s.” It should be an 
active one, based on what TAB accom¬ 
plished in 1987, the first year of the 
cycle. 

The following is a list of 1987 
achievements, along with the primary 
person or persons responsible for them: 

• “The Computer Society News” sec¬ 
tion of Computer was started up; 

TAB’S representative on the Publication 
Board became the section editor—Sallie 
Sheppard. 

• The Computer-Aided Software 
Engineering (CASE) Tools Task Force 
planned for development of three stan¬ 
dards, a computer-based tools inven¬ 
tory, and a newsletter—Robert Poston. 

• TCs have committed funds to initi¬ 
ate a satellite symposium program for 
1988—Paul Hazan and Jon Butler. 

• Global change connections were 
established with the International 
Geosphere-Biosphere Program 
(IGBP)—Bernard O’Lear. 

• The Data Base Engineering TC 
became the Data Engineering Technical 
Committee; the Data Engineering Bulle¬ 
tin will become a transaction—Sushil 
Jajodia. 

• The Software Engineering TC 
donated $15,000 to Transactions on 
Software Engineering— Lorraine 
Duvall. 

• The Neural Networks Task Force 
was started; a newsletter and conference 
were planned for 1988—Kamal Kama. 

• The TAB Self Assessment Commit¬ 
tee confirmed the need for a reorganiza¬ 
tion of TAB; detailed planning will start 
during 1988—Ned Kornfield. 

Poston’s work in organizing the 
CASE Tools Task Force, and the task 
force’s accomplishments in less than 
one year, call for special mention. The 
180-plus members of the task force have 
established goals for 1988 that include a 
Standards Impact Assessment Project 
that involves compiling a list of stan¬ 
dards that could affect professional 
tools. (Some are already in existence, 
and some, like IRDS, EDIF, SQL, 
POSIX, XWINDOWS, and IEEE Tax¬ 
onomy of Software Engineering Stan¬ 
dards, are in development.) This 
compilation will eventually include a 
brief description of each standard and 
its possible impact on professional 
tools. An impact report of this kind 
would be valuable to organizations 
building or buying professional tools. 


A group of volunteers in the task 
force is interested in producing a 
professional tools taxonomy. The group 
will start work from the tools taxonomy 
developed by the National Bureau of 
Standards and the IEEE Software 
Engineering Standards. The goal of this 
group is to develop an on-line tools 
inventory service. 

Eight technical committees have 
joined Hazan and Butler in planning a 
1988 Interdisciplinary Satellite Sympo¬ 
sium. Each TC is developing plans for 
its part of the program, outlining signif¬ 
icant trends and developments in the 
technical area. 

The Marketing and Planning Com¬ 
mittee, chaired by Kornfield, completed 
the TAB Self Assessment, and presented 
a report to the Board of Governors. 

The report showed that the technical 
committees are not well known and that 
there is a need for restructuring TAB. 
We have addressed the visibility of the 
TCs by placing news items in Com¬ 
puter. We have also participated in the 
activities of the society’s Long Range 
Planning Committee and Membership 
Development Committee. The Long 
Range Planning Committee’s top pri¬ 
ority for 1988 is TAB. 

To provide members with services in 
the future, TAB must be restructured. 
Such a restructuring would permit 
expanding current activities and engag¬ 
ing in new initiatives. At the TAB meet¬ 
ing last October 27, issues relevant to 
the expansion of technical programs 
were identified. The most important 
issues concern a mechanism to charge 
dues for membership in a technical 
committee, and the type of activities 
and services TAB should offer to 
members. 

Our discussions resulted in an action 
plan for 1988 that should culminate in 
an acceptable organization expansion 
plan, plus a financial plan to support 
the expansion. The TAB Operating 
Committee (Opcom) and the technical 
committee chairs volunteered to join in 
the effort to resolve issues in 

• finance—regarding establishing a 
viable financial model and dues 
mechanism for TAB 

• products—relative to TAB newslet¬ 
ters, annual reports, monograms, 
standards development, and other 
services to the membership 

• planning and organization— 
involving a TAB mission statement, 
operation, internal and external 
planning 


• research and development and new 
initiatives—regarding gathering 
know-how and participation in 
other leading-edge activities neces¬ 
sary to sustain the programs of the 
society, including the Interdiscipli¬ 
nary Satellite Symposium (ISS) and 
Global Change 

In conclusion, I want to thank all the 
members of the TAB Opcom and the 
technical committee chairs for their 
support and cooperation during 1987. I 
am gratified by the accomplishments we 
have made, and look forward to the 
continued effort in 1988 that will keep 
us a premier technical society. 


Late Magazines! 
No Magazines? 
Membership 
Status Problems? 
No Answers 
To Your 
Complaints? 

Let your 
Computer 
Society 
Ombudsman 
cut 
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the red 
tape 
for you. 

Computer Society 
Ombudsman 
IEEE Computer Society 
10662 Los Vaqueros Circle 
Los Alamitos, CA 90720 
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UPDATE 


Contributions to Update are welcome. Send news of industrial or university research and of public policy or professional issues to Update Editor, 10662 Los Vaqueros 
Circle, Los Alamitos, CA 90720, or to Bruce D. Shriver, Editor-in-Chief, IBM T.J. Watson Research Center, PO Box 704, H0-B04A, Yorktown Heights, NY 10598, 


NBS focuses on 
superconductivity 

The United States must be willing to 
make fundamental changes in corporate 
and government strategies to overcome 
the structural and behavioral barriers 
blocking the commercial prospects of 
superconductivity and other emerging 
technologies, said National Bureau of 
Standards Director Ernest Ambler at a 
superconductivity conference in San 
Francisco. 

Among those key barriers are inade¬ 
quate long-range planning, too much 
emphasis on product versus process 
technology, and improper integration 
of research, development, manufactur¬ 
ing, and marketing, Ambler asserted. 

Nevertheless, the US may be better 
positioned to compete with Japan in 
superconductivity because those bar¬ 
riers have been addressed somewhat 
better in this field, he concluded. 

In related activities, NBS and the 
Westinghouse Research and Develop¬ 
ment Center have produced a new 
method for making low-resistance elec¬ 
trical contacts on ceramic superconduc¬ 
tors. The high resistance, which usually 
occurs where external leads are attached 
to ceramic superconductors, is an 
obstacle to both measurements and 
practical applications. 

Researchers developed the new 
method after noticing a correlation 
between the age of many superconduc¬ 
tor samples and their contact resistivi¬ 
ties. The new method involves 
minimizing the air exposure time to 
slow the degradation of the supercon¬ 
ductor surface, sputter etching the sur¬ 
face to remove the degraded layer, and 
depositing a thin layer of a noble 
metal—silver or gold, for example—to 
protect the surface and minimize fur¬ 
ther degradation. 

Additional information is available 
from jack Ekin, Electromagnetic Tech¬ 
nology Division, National Bureau of 
Standards, Boulder, CO 80303; (303) 
497-5448. 



Donald E. Knuth 


Knuth receives 
New York Academy 
of Sciences Award 

Donald E. Knuth, a computer scien¬ 
tist at Stanford University and author 
of a three-volume study, The Art of 
Computer Programming, has received 
the New York Academy of Sciences 
Award. The citation and $5000 were 
presented at the academy’s 170th 
annual meeting in New York City. 

He was honored not only for his 
books but also for his invention of the 
automated typesetting systems TgX for 
mathematical typesetting, and 
MetaFont for the design of typefaces. 

Knuth graduated from Case Institute 
of Technology in 1960 and received a 
PhD in mathematics from the Califor¬ 
nia Institute of Technology in 1963. He 
has been a member of the National 
Academy of Sciences since 1975 and a 
fellow of the American Academy of 
Arts and Sciences since 1973. His previ¬ 
ous awards include the National Medal 
of Science, 1979; the Alan M. Turing 
Award, 1974; and the Steele Prize of 
the American Mathematical Society, 
1987. 


Conference considers 
aircraft collision 
avoidance problems 

More than 200 government and 
industry experts met recently to exam¬ 
ine the technical problems to be over¬ 
come before the Airborne Traffic-Alert 
and Collision Avoidance System 
(TCAS) can be implemented. 

Norman Jackson, head of the techni¬ 
cal department of the International Air 
Transport Assoc., representing over 160 
airlines, expressed strong support for 
such a system as a protection against a 
breakdown of the primary air-traffic 
control system. However, he high¬ 
lighted the risks of introducing an 
immature system not yet standardized 
and within an unrealistic time scale. 

The group identified numerous 
unresolved issues in technical, regula¬ 
tory, economic, and timing perspec¬ 
tives. For further details on the 
conference and related activities, con¬ 
tact David H. Featherstone, Aeronauti¬ 
cal Radio, Inc., (301) 266-4112. 

Cray awarded large 
NASA contract 

NASA’s Ames Research Center has 
awarded Cray Research a firm, fixed- 
price contract for acquisition of an ini¬ 
tial computer system with an option for 
a High Speed Processor 2 computer sys¬ 
tem for use in the Numerical Aerody¬ 
namic Simulation Processing System 
Network. 

The acquisition consists of an initial 
12-month lease, an option to lease the 
HSP-2 for 36 months, and additional 
fixed-price hardware upgrade options. 
The contract has a total value of more 
than $54 million. 

The HSP-2 system will be capable of 
performance exceeding 1 billion 
floating-point operations per second in 
sustained computation with at least 2 
billion bytes of common memory and at 
least 50 billion bytes of high-speed mass 
storage. 
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Computer network for researchers 
to be expanded 


The National Science Foundation has 
entered into a $ 14-million, five-year 
agreement with Merit, Inc., of Ann 
Arbor, Michigan, to enhance computer 
connections between the nation’s scien¬ 
tific research centers, greatly upgrading 
the performance and capacity of exist¬ 
ing regional linkages. 

The high-speed network eventually 
will link thousands of researchers work¬ 
ing across the nation in technology, 
space exploration, medicine, defense, 
and other programs that require exten¬ 
sive communication and computation. 

Merit is a consortium of eight state- 
supported colleges and universities in 
Michigan that operates a computer net¬ 
work linking the schools. IBM, MCI 
Communications, and the Michigan 
state government, through its Strategic 


Computer experts have warned a con¬ 
gressional subcommittee that current 
proposals for the expansion of the 
National Crime Information Center 
threaten the privacy and civil liberties of 
individual citizens. The computer 
experts, members of Computer Profes¬ 
sionals for Social Responsibility 
(CPSR), say changes being considered 
would expand the NCIC to contain 
highly sensitive information without 
adequately safeguarding the security 
and integrity of the information in the 
system. 

The NCIC is the nation’s largest cen¬ 
tralized criminal justice information 
database. It is administered by the FBI 
and accessed by 64,000 local, state, and 
federal criminal justice agencies. CPSR 
reports that the NCIC Advisory Policy 
Board is considering 

• adding records of misdemeanors 
and juvenile offenses to criminal 
history records 

• linking the NCIC with existing 
computerized databases at the 
Internal Revenue Service, the Social 
Security Administration, the Secu¬ 
rities and Exchange Commission, 
and the Immigration and Naturali¬ 
zation Service 

• giving the NCIC the ability to track 
individuals, including those under 
investigation but not charged with a 
crime 

CPSR’s experts say that without an 


Fund, have joined with Merit to 
develop and support the enhanced 
network. 

Merit will integrate and operate the 
communication and switching equip¬ 
ment for the NSF network (NSFNet). It 
will also build a team of support per¬ 
sonnel to operate the network and man¬ 
age its growth and development over 
the life of the agreement. 

IBM will develop software and pro¬ 
vide hardware for switching systems 
located at each NSF supercomputer site 
and regional network center. The 
switching system will be based on 
TCP/IP standards and will evolve over 
the term of the agreement to the pro¬ 
posed Open Systems Interconnect 
standards. 


overall design strategy ensuring system 
security, data integrity, and user 
authentication and accountability, it is 
impossible to ensure that the system can 
adequately protect its records or guar¬ 
antee their accuracy. 

The CPSR evaluation was requested 
by Rep. Don Edwards (D-CA), chair¬ 
man of the House Subcommittee on 
Civil and Constitutional Rights, which 
has oversight responsibility for the FBI. 

Following a meeting of the NCIC 
Advisory Policy Board in December, a 
CPSR spokesperson reported that the 
plan to link NCIC with other govern¬ 
ment agency databases had been put on 
hold. However, the idea of enabling the 
NCIC to track individuals, whether 
charged with a crime or not, was “still 
alive.” Implementation might start with 
a couple of categories and be expanded 
later. 

Information about the deliberations 
of the NCIC Advisory Policy Board is 
available from James X. Dempsey, 
assistant counsel, Subcommittee on 
Civil and Constitutional Rights, Com¬ 
mittee on the Judiciary, US House of 
Representatives, (202) 226-7680. 

CPSR is a nonprofit public-interest 
organization of people in the computing 
field who are concerned about the 
impact of computers on society. The 
organization can be reached at PO Box 
717, Palo Alto, CA 94301; (415) 
322-3778. 


Contest to award 
cash and computers 

NCR is offering a $50,000-cash first 
prize for the best essay by a college or 
university student on the “stakeholder” 
approach to management. The winning 
student’s school will receive NCR com¬ 
puter systems worth $100,000. 

In addition, a second prize of $15,000 
in cash for the student and $35,000 in 
computers for the student’s school is 
being offered. Another 100 semifinalists 
will receive $1000 each. 

The topic for the essay competition is 
“Creating Value for All Stakeholders in 
Corporations and/or Not-for-Profit 
Organizations.” Stakeholders include 
customers, employees, suppliers, share¬ 
holders, governments, and the financial 
community. 

Complete rules for the competition 
were to be distributed to campuses in 
mid-January. 


Society for Integrated 
Manufacturing formed 

The Institute of Industrial Engineers 
has formed the Society for Integrated 
Manufacturing to provide expanded 
service to members interested in this 
specific field. 

SIM will promote and support the 
practice of industrial engineering as it 
concerns the full cycle of part and prod¬ 
uct fabrication and distribution. This 
includes process and equipment design 
and selection; systems design and con¬ 
trol; facilities design, specification, and 
maintenance; inspection and assembly 
operations; quality assurance; produc¬ 
tion and inventory control; and utiliza¬ 
tion of modern computer and 
automation methods. 

The society will offer its members 
conference programming at IIE confer¬ 
ences, regional seminars and confer¬ 
ences, recognition of membership 
achievement through the IIE award 
structure, newsletters, a practice- 
oriented technical journal, a 
resume/job bank or job fair at confer¬ 
ences, a salary survey, a member proj¬ 
ect roster, a technical speaker list, and 
on-line information services. 

For further information, contact 
Society, Division, and Interest Group 
Services Manager, Institute of Indus¬ 
trial Engineers, 25 Technology 
Park/Atlanta, Norcross, GA 30092; 
(404) 449-0460. 


Civil liberties issue raised in 
expansion of federal database 
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ADVANCE ANNOUNCEMENT 



10 th International 
Conference on 


SOFTWARE 

ENGINEERING 


April 11-15,1988 • Singapore 


Tools of a Profession 

I n any discipline, and in software especially, there are several kinds of tools. The most obvious tools are tangible: software tools, or 
second-degree software, used in the production of other software; hardware tools, necessary to improve the efficiency of the 
production process; methodological tools, which guide a systematic process of software construction; and linguistic tools, which 
define the formalisms in which ideas and their implementations will be expressed. The 10th 1CSE will devote itself to an assessment 
of current advances in these four directions. 


The Conference 


The City 


The conference will begin with tutorial sessions designed to provide 
in-depth instruction on the following topics; 

■ Knowledge-Based Programming Environments 

■ Software Risk Management 

■ Peopleware: Productive Projects and Teams 

■ Formal Specification and Verification 

Topics scheduled to be discussed in technical sessions include: 

■ Parallel and Distributed Applications ■ Management 

■ Distributed System Design ■ Environments 

■ Software Quality Techniques ■ Process Models 

■ Specifying Concurrent Systems ■ User Issues 

■ Software Derivation ■ Real Time 

The Software Tbols Fair will be held in conjunction with the confer¬ 
ence sessions. The Fair is comprised of two parts, the Tools Exhibition 
and the Tools Presentation Track and will provide exposure to the latest 
commercial and experimental software tools. 

To further enhance the sharing of research results and experiences, a Tech¬ 
nical Visit Programme is scheduled for April 16. 1988. Participants will 
visit six of Singapore's key research institutes and information technol¬ 
ogy centers. 


Several attempts have been made to ensure that attendees have an oppor¬ 
tunity to enjoy the city of Singapore. 

On the second evening of the conference, all attendees are invited to a 
complimentary show cum banquet. Through the use of song and dance, 
the show "MALAM SINGAPURA" will unfold the colorful and interesting 
cultures of Singapore. At the conclusion of the show you can enjoy a deli¬ 
cious 10-course Chinese banquet. 

In addition, Associated Tours Singapore Pte. Ltd. has arranged several post¬ 
conference tour packages. Trips include the Singapore City Tour, a Twilight 
Dinner Cruise and a full day Malacca tour. 


For further information on the 10th International Conference on Soft¬ 


ware Engineering, please contact: 
10th ICSE Secretary or 

National Computer Board 
71 Science Park Drive 
NCB Building 
Singapore 0511 
Tel 65-7720405 
Fax: 65-7795966 
Telex: RS 38610 NCB 
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NEW PRODUCT REVIEWS 


Editor; Richard Eckhouse, MOCO, Inc., PO Box A, 91 Surfside Rd., Scituate, MA 02055; Compmail + , r.eckhouse 


Easy-to-use screen interface systems 

Daniel McAuliffe, McDonnell Douglas Electronics 
Richard Eckhouse, MOCO, Inc. 


One of the main tasks in developing 
usable applications software for per¬ 
sonal computers involves designing 
presentable data entry formats and 
assembling an uncluttered user inter¬ 
face. While this task can be formidable, 
several systems greatly simplify it. 

These systems span a wide range in 
terms of ease of use, flexibility, pro¬ 
gramming knowledge required by the 
user, and user interface. We take a look 
here at four such systems, each fitting a 
particular user niche. 


Say what?! 

Saywhat?! is a straightforward pro¬ 
gram that allows you to generate a text- 
image screen that includes fill-in fields 
and moving-bar menus. Once designed, 
these screens are kept as compressed 
files that can be called up using a 
memory-resident program invoked by 
passing the control sequence CHR(255) + 
CHR(255) + ” < command string>/”. 
Using an option during screen genera¬ 
tion, you can generate source code to 
call up the screen from Pascal, dBase, 
or Basic. Alternatively, you can write a 
batch file that includes a command to 
call up the Saywhat?! screen and exe¬ 
cute an IF ERRORLEVEL batch com¬ 
mand when the user selects a field in 
moving-bar menus; its number is passed 
back as an error-level code. 

Making screens with the Saywhat?! 
editor is a snap. The 23 commands 
allow you to build screens quickly and 
easily. Video attributes include full con¬ 
trol of color, underlining, blinking, and 
intensity, as well as an extended charac¬ 
ter set. Boxes are easily drawn and, if 
overlapping, joined together. Paint and 
fill commands let you add lots of color, 
while move and center help you put 
things where you want them. You can 
combine as many as 100 compressed 
screen files into a single library file for 
later recall using the memory-resident 
program. A view-library function not 
only helps you to make a library, but 
also to manage images once created. 


The 100-page manual that comes with 
Saywhat?! is well organized and very 
thorough. It includes many examples 
and a complete index. Also, the many 
samples that come with the program 
make it easy to understand the range of 
possibilities as well as providing a model 
for designing new screens. Finally, one 
of the utilities included allows you to 
import screens created by other programs. 

This package has a few limitations. 
First, you can have 64 fields per screen 
at most. Second, you can have only one 
vertical or one horizontal moving-bar 
menu. Third, the minimal nature of 
programs generated by Saywhat?! 
means that you have to write your own 
code for validating the data entered. 

However, at $50, with no copy pro¬ 
tection, a liberal commercial use 
license, and a money-back guarantee, 
this software is a real bargain. System 
requirements are 192K bytes, an IBM 
PC or compatible, and DOS 2.0 or 
higher. The program is lightning fast, 
flexible, and fun to use. We recommend 
it highly. 
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Flash-Up and Flash-Up 
Developer’s Toolbox 

If you’re looking for more features 
and functionality than Saywhat?! 
offers, Flash-Up and Flash-Up 
Developer’s Toolbox may be just the 
thing. For a little more money ($89 for 
Flash-Up and $49 for Developer’s Tool¬ 
box), you get much more than a win¬ 
dowing system. Flash-Up combines 
macros, menus, and a note maker 
within a windowing system. It also 
includes a screen capture program. 

Using the well-done WYSIWYG win¬ 
dow editor, you can create menus and 
help screens that will flash up inside 
other programs. You can attach the 
windows to any keyboard keys for 
instant recall. Because the windows can 
be made content and cursor-location 
sensitive, Flash-Up knows the correct 


notes and keys to associate with the cor¬ 
responding data entry screens. 

Using the editor or on-line recording 
of a macro, you can associate long 
sequences of commands with one or 
two keystrokes. You can also create 
menus that show which macros are 
available. A cut-and-paste facility 
allows you to take screen information 
from one program and copy it into 
another. And mouse support is built 
into Flash-Up, so it’s always at the 
ready. 

Like other Software Bottling 
products we’ve tested, this system is 
easy to use. The manuals are brief and 
to the point, covering all the essentials, 
so it’s easy to generate menus almost 
immediately. The editor comes with its 
own set o£ pull-down menus and help 
screens. There are no commands to 
remember, and menu changes (such as 
size, location, border, coloring, or 
attachment to a window) are immedi¬ 
ate. Other menu selections save and 
restore menus to libraries, set up key¬ 
board macros, initiate special flash-up 
commands, and specify options (such as 
the hot-key to activate Flash-Up). 

The non-copy-protected system runs 
on an IBM PC or compatible, uses 
128K bytes as a memory-resident pro¬ 
gram, and requires a floppy disk and 
any 80-column monitor. 

The optional Developer’s Toolbox 
runtime system cuts the memory 
requirements in half by cutting out the 
editor and other menu and window 
development tools. Once you’ve devel¬ 
oped your screens, the memory-resident 
runtime module intercepts commands 
from all the popular programming lan¬ 
guages, as well as through batch com¬ 
mands, so that you can access the 
Flash-Up windows from virtually any 
application. This add-on product is 
clearly designed for programmers who 
want to avoid the hassle of creating 
windows while gaining all the function¬ 
ality windows offer. 

The Software Bottling Company 
recognizes that programmers may wish 
to include windows and macros with an 
application. Hence, the company allows 
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you to distribute the runtime system 
without paying additional royalties. 

We really liked working with both 
Flash-Up and the Developer’s Toolbox, 
and we recommend them highly. 
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Basic development tools 

Sterling Castle has bundled four 
“automatic programming” tools in one 
package to assist the applications pro¬ 
grammer. The four modules are the 
Screen Builder, B + Tree Data Man¬ 
ager, EZ Screen Pop-Up Window Man¬ 
ager, and Help Message system. 

The Screen Builder is unlike the 
others described here in that it lacks the 
“look and feel” that make the others so 
fun and colorful to use. Instead, you 
get the code necessary to manage the 
displays and fields you specify in a 
more basic manner. 

For example, to specify a field, you 
use square brackets to delimit it and an 
A, N, or U to specify the data type 
allowed. While graphic boxes may be 
drawn manually or indicated by the use 
of curly brackets, and special characters 
may be inserted from the full ASCII 
character set, the end result is still 
rather primitive. What really distin¬ 
guishes this system is the program 
generator, which produces full-fledged 
programs to create screens, check data 
field validity, and store data records. 

Two other modules manage help mes¬ 
sages and pop-up windows. You can 
create the help messages with any 
ASCII text processor, or with the sim¬ 
ple editor included with the system. The 
messages may take up to 100 lines or 
four full screens. Messages use and 
restore full screens. The pop-up win¬ 
dows module comes with 13 functions 
to save, clear, scroll, erase, and restore 
menus, windows, and help screens. The 
most serious limitation in the version 
reviewed here was that it did not sup¬ 
port Enhanced Graphics Adapter 
screens. 

To quote from the manual: 

The B + Tree algorithm is a data file index 
method. This method provides direct and 
sequential access to data stored in BASIC 
data files. This index is comprised of a key 
for each data record and a physical record 
number associated with the key. The 
B + Tree algorithm does not deal with the 
storage of data, but only maintains 
indexes [SIC]... 

All in all, this set of modules does not 


constitute an automatic program gener¬ 
ator, but rather a set of programs that 
helps you develop applications quicker. 
The manual is thorough enough to pro¬ 
vide the information needed to use the 
programs and includes enough samples 
to demonstrate significant applications. 
However, these programs are not for 
the casual user wanting to add a little 
pizzazz to his programs. 

The four-program package costs $99. 
A suitable configuration is a standard 
IBM PC or compatible with a floppy 
disk drive, DOS 2.0 or greater, and 
enough memory to run Basic, Turbo 
Basic, or Quick Basic. The system is not 
copy protected. 
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C-scape 

What really sets C-scape apart from 
the other systems is that it is a complete 
collection of C functions for managing 
screens. In one sense it is a program¬ 
mer’s toolbox, while in another it is an 
applications generator that converts 
your screen image into a full- fledged C 
program. In addition, the syntactic 
structure has been made to look as 
familiar to the C programmer as the 
Printf function, so you immediately feel 
comfortable with the new features this 
system has to offer. 

The C-scape Interface Management 
System—together with the Look & Feel 
Screen Designer—goes a long way 
toward making the design of presenta¬ 
ble data entry formats and the assembly 
of an uncluttered user interface an easy 
and painless process. Look & Feel 
allows you to build complex data entry 
screens with minimum effort. You can 
define protected fields and a variety of 
unprotected field types such as integer, 
character, and date. You can also 
attach prompt messages to each field 
and your own C functions to process 
the field if none of the standard func¬ 
tions meet your needs. Look & Feel can 
then be used to generate source code 
that your program can use to produce 
the screen. This is a tremendous time 
saver, especially since you no longer 
have to spend time calculating row and 
column values for field placement. 

C-scape provides a rich collection of 
functions for producing a large variety 
of menus, including pull-down menus, 
pop-up menus, Lotus 1-2-3-style menus, 
and even exploding windows. In order 
to use some of the higher level menu 
systems, you need only define the menu 


entries in a C-scape structure and then 
invoke the appropriate function. Low- 
level video and keyboard functions 
allow you to build your own menu 
types. We expect you would rarely need 
to do this, considering the flexibility of 
the built-in menu types. C-scape also 
provides an extensive and very easy-to- 
use help system. 

The documentation for C-scape and 
Look & Feel consists of a 500-page 
7 x 9-inch bound manual. The first 
100-plus pages consist of a well written 
introduction and explanation of the C- 
scape concepts, with numerous exam¬ 
ples. The remainder of the manual pro¬ 
vides an alphabetical listing of the 
C-scape functions with examples. The 
disks supplied with the package contain 
more detailed examples of fully 
executable programs. In every respect, 
the manual is professionally done and 
easy to use. 

We used the Microsoft C 4.0 version 
of C-scape on an IBM PS/2 Model 50. 


Computer 
Science and 
Engineering 



Applications are invited for gradu¬ 
ate study at a unique institution 
where students take an active part 
in state-of-the-art research. Facili¬ 
ties include comfortable offices with 
terminals/workstations, VLSI design 
lab, Smalltalk/PROLOG environ¬ 
ments, parallel computing main¬ 
frames. The Department offers fully 
accredited MS and PhD programs. 
The Tektronix Fellowship pays a 
$10,000/year stipend. The Tek¬ 
tronix Co-op program offers work- 
study with an industry leader. 
Research assistants participate in 
projects such as: 

parallel supercomputers 
connectionist/neural-networks 
knowledge-management systems 
interactive graphical interfaces 
text-processing systems 
functional and logic programming 
object-oriented databases 
engineering design environments 
large-grain data flow 
software engineering theory 
For applications and information: 
OGC Education Office 
19600 N.W. von Neumann Drive 
Beaverton, OR 97006 
(503) 690-1028 

Deadline is 15 March 1988. 
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We began by building a data-entry form 
with the Look & Feel Screen Designer. 
After manipulating the form in a num¬ 
ber of different ways, we used Look & 
Feel to generate a C language test pro¬ 
gram to see how the form looked. We 
then modified the program using a vari¬ 
ety of the functions provided by C- 
scape. The exercise was a pure joy, 
primarily due to the ease of use and the 
extensive set of high-level functions 
included in the package. 

We have used a number of different 
screen management systems in the past, 
but C-scape is by far the best we’ve 
encountered to date. If you are in the 
market for such a system, we recom¬ 
mend that you give serious consider¬ 
ation to C-scape. 

The C-scape list price is $279. This 
includes the source code and telephone 
support. It is available for a number of 
different compilers, including Borland, 
Lattice, and Microsoft. An identical 
package without the source code or tele¬ 
phone support is available for Turbo C 
for $99.95. 
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Product notes 

• Interested in an integrated micro- 
to-mainframe software package that 
provides 3270 emulation for coax, 
remote, and LAN connections? If 
so, consider Extra! Release 1.2 from 
Attachmate Corporation, 3241 118th 
S.E., Bellevue, WA 98005, (206) 
644-4010. 

• “Ask Dan” is claimed to be the 
first knowledgeable tax software 
using expert system technology. This 
well-done, comprehensive package 
uses on-screen tax forms, pull-down 
menus and pop-up scratch pads, cus¬ 
tomized checklists with preparation 
assistance, and context-sensitive 
questions that allow for flexible 
interactions with the underlying 
expert system. The program sup¬ 
ports 24 forms along with a 
scenarios worksheet that allows the 
user to try combinations of “what 
if” sequences. A great help in organ¬ 
izing the user’s data, this $70 system 


is available from Legal Knowledge 
Systems, Inc., 195 Maplewood 
Street, Watertown, MA 02172, (617) 
923-2322. An IBM PC or compatible 
with 512K is needed and a hard disk 
is recommended. 


• Looking for the “Cadillac” in 
high-resolution monitors? The 
Princeton Graphic Systems 
Ultrasync PS/2 offers IBM PC and 
PS/2 as well as Macintosh II com¬ 
patibility, a ,28-mm dot pitch, 

800 x 600 resolution, and automatic 
screen adjustment in all modes. 
Priced competitively with NEC, 
Sony, and Mitsubishi multiple scan 
monitors, this $795 monitor with its 
45-120 FIz vertical and 15-35 KHz 
horizontal scan rates should be a 
serious new contender in the market¬ 
place. Princeton Graphic Systems is 
located at 601 Ewing Street, Bldg. A, 
Princeton, NJ, (609) 683-1660. 


Tektronix 

COMMITTED TO EXCELLENCE 


Research Opportunities in Oregon 

Positions are available in the Computer Research Laboratory, a division of Tektronix Laboratories. 
The mission of the Lab is to monitor, explore, and develop the potential capabilities of 
emerging technologies in computer science and engineering in order to provide technology- 
based product opportunities for our operating divisions. 

The Lab currently has a staff of about 50 persons with technical interests in a variety 
of computer research areas. Active research projects are in place in the areas of advanced 
computer system architectures, distributed data bases, applicative and functional languages, 
software specification, knowledge engineering and expert systems, symbolic and algebraic 
computation, and algorithms for computer-aided engineering. Openings exist for candidates 
with an MS or PhD in CS or EE (or equivalent experience) with appropriate background. 

The Lab provides an excellent research environment. The computational facilities are 
among the best in the nation. Located near Portland, Oregon, the Lab is within a two- 
hour drive of the beautiful Cascade Mountains and Pacific Ocean beaches. The Portland 
metropolitan area offers a nationally acclaimed quality of life and a wide variety of cultural 
and recreational opportunities. 

Tektronix offers competitive salaries and excellent benefits, including liberal educational 
support, health and retirement plans, and profit sharing. 

If the opportunities at Tektronix sound attractive to you, please send your resume to: 
Recruiting Committee, Computer Research Lab, MS 50-662, Tektronix, Inc., P.O. Box 500, 
Beaverton, OR 97077. The net address is abdali@tekchips.tek.com. 

We are an equal opportunity employer, m/f/h/v. 
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NEW PRODUCTS 


Second-generation Clipper doubles performance 


Atari offers networking 
with Moses PromiseLAN 

Atari has announced a local area net¬ 
work called Moses PromiseLAN, which 
reputedly connects up to 17 PCs in a 
star configuration using telephone wire. 
According to the company, the soft¬ 
ware meets Net bios standards. 

Moses PromiseLAN connects IBM 
PCs and compatibles and provides an 
interface to Appletalk, permitting the 
connection of Apple Macintosh com¬ 
puters to the network. Atari is develop¬ 
ing adaptors for its Mega and ST 
computers. 
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IBM expands desktop 
publishing solutions 

IBM’s SolutionPac Personal Publish¬ 
ing Option/A combines hardware and 
software for the creation of in-house 
documents on the Personal System/2 
Models 50, 60, and 80. Option/A 
includes the IBM 4216 Personal 
Pageprinter, a laser printer; Personal 
Pageprinter Adapter/A, an adapter 
card; Personal Pageprinter Adapter 
Licensed Program Version 1.2, the pro¬ 
gram that controls Adapter/A; publish¬ 
ing software; and PS/2 mouse. 

The publishing software for 
Option/A includes the Adobe Post¬ 
script page description language, Aldus 
Pagemaker document composition soft¬ 
ware, and Microsoft Windows system 
environment manager. 

The Personal Publishing Option/A 
costs $5888. 

IBM also offers new releases of Pub¬ 
lishing Systems Bookmaster and 
Browsemaster for host-based users in 
the Multiple Virtual Storage operating 
system environment. 

The MVS versions of Bookmaster 
and Browsemaster have monthly license 
fees of $330 and $115, respectively, and 
one-time charges of $8500 and $3500, 
respectively. 

Option/A: Reader Service 32 
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Intergraph has announced the second 
generation of the Clipper 32-bit com¬ 
puter architecture. The Clipper C300 
reportedly runs at clock rates up to 50 
MHz and more than doubles the perfor¬ 
mance of the original Clipper C100 
while remaining plug compatible. 

The C300 module incorporates three 
chips: a CPU chip with an IEEE- 
standard floating-point unit and two 
cache-plus-memory-management units, 


Unisys has added two new models to 
the upper range of its A Series of main¬ 
frame computers. The new systems are 
object code compatible with Unisys B 
5000, B 6000, and B 7000 mainframes, 
according to the company, and employ 
the Master Control Program/Advanced 
System operating system. 

The five A 17 models are configured 
with one to four processors. They fea¬ 
ture the Resource Management Module, 
which reportedly frees the central 
processor of task management func¬ 
tions and input/output duties. Main 
memory expands from 48M bytes to 
288M bytes in 24M-byte increments. 


BBN Advanced Computers offers an 
enhanced version of its Butterfly paral¬ 
lel processor called the Butterfly Plus. 
The shared-memory Butterfly Plus con¬ 
sists of up to 256 processors reputedly 
providing 600 MIPS of performance 
and up to a gigabtye of shared memory 
in maximum configuration. 

According to the company, hardware 
improvements include 32-bit data and 
address paths; a new memory manage¬ 
ment unit; additional on-board diagnos¬ 
tics; and field-installable microcode. 

The system’s processor node is based 
on the 32-bit Motorola 68020 
microprocessor and includes a Moto¬ 
rola 68881 floating-point coprocessor, 
four megabytes of on-board memory, 
and a Motorola demand paged memory 


one for instructions and one for data. 

Clipper C300 modules will be avail¬ 
able in sample quantities during the sec¬ 
ond quarter of 1988, with volume 
deliveries scheduled for the third quar¬ 
ter. It is being developed and will be 
marketed by the Advanced Processor 
Division in Los Altos, Calif. 
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Prices are $3.1 million for the one- 
processor A 17F; $4.4 million for the 
two-processor A 17H; $5.6 million for 
the two-processor A 17J; $7.3 million 
for the three-processor A 17L; and $8.9 
million for the four-processor A 17N. 
Models F, H, and J will be available in 
May 1988 and models L and N, in June 
1988. 

The A 12E is a single-processor sys¬ 
tem for $795,000. Main memory 
expands from 24M bytes to 72M bytes 
in 24M-byte increments. 
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management unit. 

Butterfly Plus reportedly supports 
both Multibus and VMEbus devices. It 
uses BBN’s Chyrsalis operating system 
and can be programmed using a variety 
of languages, including C, Fortran-77, 
and Scheme. Programs are written on a 
front-end system. 

A 30-processor, 75-MIPS, 120M-byte 
memory Butterfly Plus with software 
costs around $400,000. 

Current Butterfly users can upgrade 
to a Butterfly Plus through a processor 
node trade-in program. The Butterfly 
Plus can be upgraded to the GP1000 
Unix-based system and the planned 
RT1000 real-time system. 
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BBN Butterfly Plus shares memory 


Unisys adds new models to A Series mainframes 
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CALL 

FOR 

PAPERS, 

TUTORIALS, 

AND VENDOR 

PROPOSALS 


CONFERENCE ON 
SOFTWARE MAINTENANCE-1988 

PHOENIX, ARIZONA 
OCTOBER 24-27, 1988 


The Conference on Software Maintenance—1988 (CSM-88) will gather software managers, developers, maintainers, 
and researchers to discuss new solutions to the continuing challenge of software maintenance and software 
maintainability. 

Making a Difference: Improving The Product By Improving The Process 

CSM-88 will focus on the processes that impact software maintenance. CSM-88 seeks papers which clearly indicate advances in the field of 
software maintenance; the time frame for achieving those advances; and any evidence suggesting that the advances can in fact be realized. 
Papers which indicate paths that should not be followed, along with evidence supporting these conclusions, are also solicited. 


SPONSORS: 


IN COOPERATION WITH: 


ACM/SIGSOFT- 

Special Interest Group on Software Engineering* 


0 ^ 


The Institute of Electrical and Electronics Engineers, Inc. 
Data Processing Management Association (DPMA) 
National Bureau of Standards (NBS)* 


Association for Women in Computing (AWC)* 
Software Maintenance Association (SMA)* 


SUGGESTED TOPICS 

Paper and panel sessior proposals 
related to, but not limited to. the following 
topics are invited: 

■ Software Maintenance Environments 

■ Empirical Maintenance Studies 

■ Software Maintenance Metrics 

■ Maintenance of Ada 1 " Programs 

■ Artificial Intelligance in Software 
Maintenance 

■ Software Reusability in Maintenance 

■ Configuration Management 

■ Developing Maintainable Systems 

■ Standards in Software Maintenance 

■ Maintenance of Distributed Systems 

■ Maintenance of Fourth Generation 
Programs 

■ Software Maintenance Education 

■ Acquisition of Software Maintenance 
Services 

■ Software Testing 

■ Impact of PDLs on Software 
Maintainability 

■ Restructuring/Reengineering 

” Trademark of the U S. Department of 
Defense 


SCOPE AND PURPOSE 

Software Maintenance is the enhancement, restructuring and correction of software in production 
use. CSM-88 will provide a forum for discussing software maintenance, distilling current 
experiences, and highlighting promising approaches, through presentations of refereed papers, 
panel sessions, tutorials, informal meetings, and tool demonstrations. CSM-88 will acquaint 
managers and practitioners with current advances and researchers with current needs. The 
conference is open to all who are involved with or have an interest in software maintenance: 
professionals and researchers, from industry, Government, and academia. 

IMPORTANT DATES: 

Submission Deadline: March 18, 1988 

Acceptance Notification: April 18, 1988 
Final Version: May 30,1988 


SUBMISSION INFORMATION 

Papers: (5 copies double spaced) Papers should be 1000-5000 words in length. Papers must 
not have been published or submitted elsewhere for publication. The cover letter must include: 
title and maximum 250 word abstract only. The first page must include title, all authors' names, 
complete mailing addresses, and telephone numbers. If the paper is accepted, one of the 
authors is expected to present the paper at CSM-88. 

Panel Session Proposals: (5 copies) Panel session proposals must include: name of panel 
session organizer, mailing address, and telephone number, panel topics, significance for CSM-88, 
and a list of 4-5 panelists. Panelists must have agreed to participate prior to the submission 
of the panel session proposal. 

SUBMIT PAPERS AND PANEL SESSION PROPOSALS TO WILMA M. OSBORNE AT HER 
ADDRESS BELOW. 

Vendor Proposals: Send for information from Robert Arnold at his address below. 

Tutorial Lecturers: Send for information from Wilma Osborne at her address below. 


GENERAL CHAIR 

Robert Arnold 
Software Productivity 
Consortium (SPC) 
1880 Campus Commons 
Drive, North 
Reston, VA 22091 
(703) 391-1898 


CONFERENCE COMMITTEE 


PROGRAM CO-CHAIR 

Wilma Osborne 
National Bureau of 
Standards 

Bldg. 225, Rm. B266 
Gaithersburg, MD 20899 
(301) 975-3339 


PROGRAM CO-CHAIR 

Thomas Corbi 

IBM Hawthorne Research 

P.O. Box 704 

Yorktown Heights, NY 10598 
(914)789-7654 


IMMEDIATE PAST 
GENERAL CHAIR 

Roger J. Martin 
National Bureau of 
Standards 

Bldg. 225, Rm. B266 
Gaithersburg, MD 20899 
(301)975-3295 











DEC offers new MicroVAX II configuration 


Digital Equipment offers a new 
MicroVAX II system configuration, 
plus enhancements that incorporate the 
most recent tape and communications 
options into the MicroVAX II series. 

The new configuration, based on the 
entry-level office system (configuration 
3), features a single RD54 fixed disk 
drive with 159M bytes of mass storage. 

MicroVAX II standard configura¬ 
tions 4 and 5 now include Digital’s 
TK70 streaming-tape subsystem. The 
TK70 provides 296M bytes of formatted 
capacity. It is also available as an 
option. 

DEC now supplies their newest Q-bus 


communications controller and Ether¬ 
net adapter on all MicroVAX II 
systems. 

The communications controller, 
DHQ11, is an eight-line, asynchronous, 
direct-memory access multiplexer for 
connecting local terminals to Micro¬ 
VAX II systems. 

The Ethernet adapter, DELQA, is a 
Q-bus network adapter used to connect 
the MicroVAX II to local area 
networks. 

Pricing for the new MicroVAX II 
configuration starts at $33,900. 
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Software makes VAX an AppleShare file server 


Pacer Software has announced Pacer- 
Share, a software package that reput¬ 
edly enables any Digital Equipment 
VAX/VMS system to function as an 
AppleShare-compatible file server. 

According to the company, by imple¬ 
menting the Apple Filing Protocol on a 
VAX system, the Pacer product enables 
a VAX to act as a file server for a 
Macintosh network. Users can employ 
the Macintosh mouse and graphical 
interface to peruse the VMS file system, 
create directories, move directory trees, 
or access any VMS file type from within 
a standard Macintosh application. 

Pacer asserts that the VAX file sys¬ 
tem is viewed from the Macintosh as a 
series of hierarchical volumes with 


VAX directories represented as folders. 
Individual files are available to both 
Macintosh and VAX applications. 

The VAX AppleShare server report¬ 
edly conforms to VMS system security. 

PacerShare requires Pacer’s pcLink 
on the VAX and Macintosh connections 
through Ethernet. The VAX must also 
have a standard Ethernet controller 
card. 

Pricing depends on the number of 
concurrent user sessions. For five ses¬ 
sions on a MicroVAX, PacerShare costs 
$400 and pcLink, $2000. PacerShare 
will be provided to current pcLink cus¬ 
tomers for no additional charge. 
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ALR micros use flexible bus architecture 


Advanced Logic Research has 
announced the Flexcache 386 series of 
16- and 20-MHz microcomputers based 
on ALR’s Flexcache architecture, which 
relies upon flexible bus design and 
cache memory. 

The Flexcache 16386 is a 16-MHz, 
zero-wait-state system based on the 
Intel 80386 and 82385 chips. The Flex¬ 
cache 20386 is a 20-MHz, zero-wait- 
state system based on the Intel 80386 
and 82385 chips. The Intel 82385 cache 
memory controller features 32K bytes 
of 35-ns static RAM. 

A hard disk controller with a 1:1 
interleave, plus a full-track buffering on 
the ESDI controller, reputedly increases 
overall disk performance. According to 
the company, ESDI hard disk drives in 
the 150 and 300M-byte systems achieve 


a disk access time faster than 23 mil¬ 
liseconds. 

The ALR systems come with up to 
630M bytes of fixed disk storage. The 
floor-mount chassis reportedly accepts 
up to two full-height hard disk drives 
and three half-height devices. Expan¬ 
sion slots include two 8-bit, four 16-bit, 
and two flex-chache 32-bit slots. 

The ALR Flexcache 16386 Model 60 
with a 66M-byte hard disk costs $4690. 
The Flexcache 16386 Model 100 with a 
lOOM-byte hard disk costs $5690. The 
Flexcache 20386 Model 150 with a 
150M-byte hard disk costs $7490 and 
the Model 300 with a 300M-byte hard 
disk costs $9990. 
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Free Space compresses data 

Ashton-Tate’s Publishing Group has 
announced Free Space, a software util¬ 
ity for data compression. According to 
the company, the product works partic¬ 
ularly well with dBase and Lotus files. 

Once installed, Free Space creates a 
new logical disk that can be used like 
any other disk, supposedly eliminating 
the need to manipulate compressed files 
to access them. As data is written to the 
device, files are compressed; as files are 
read, they are decompressed. Files are 
contained in the standard PC-DOS file 
structure. 

Free Space can also be password- 
protected. 

According to the company, Free 
Space’s compressed disk operates with 
hard disks, floppy disks, and device 
driver-supported storage devices. It 
operates on PC-DOS or MS-DOS 2.1 or 
higher. 

Free Space, developed by Stoneax 
Associates, costs $69.95. 
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Kit helps develop 
neural networks 

Science Applications International 
Corp. has released the Artificial Neural 
Systems Simulation software kit, called 
ANSkit. 

According to the company, the kit 
allows the novice or expert to develop a 
neural network for a particular applica¬ 
tion. The kit contains 12 user- 
configurable neural models plus an 
interface to dBase III and Lotus 1-2-3 
for knowledge processing. 

ANSkit comes with Microsoft Win¬ 
dows, an optical mouse, ANSim 
documentation, Parallel Distributed 
Processing from MIT Press, and a 
videotape entitled “An Insight to Arti¬ 
ficial Neural Systems.” It costs $995. 

System requirements are MS-DOS 
3.1, 640K bytes of RAM, an EGA 
adaptor and monitor, RS-232 serial 
port, and a hard disk drive. 

Version 1.1 includes the neural 
models Adaptive Resonance II, Hop- 
field Network, Boltzman Machine, 
Hamming Network, Back Propagation, 
and Back Propagation with shared 
weights. Version 1.2 includes these 
models plus Adaptive Resonance I, 
Bidirectional Associative Memory, 
Kohonen Feature Map, Back Propaga¬ 
tion Recurrent Networks, Boltzman 
Learning, and Counter Propagation. 
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CIM modeling on Macintosh 

Meta Software offers Design/IDEF, 
a computer-integrated manufacturing 
modeling and planning tool for the 
Apple Macintosh Plus, SE, and II. 
According to the company, this 
graphics tool can handle CIM models 
containing hundreds of hierarchically 
linked diagrams. 

Major features include graphics for 
automated model creation; automated 
arrow joins, branches, bridges, and tun¬ 
nels; automatic maintenance of object 
connections; an interactive data diction¬ 
ary; a data capture facility for report 
generation; and text handling capa¬ 
bility. 

Design/IDEF sells for $2000 until 
March 31, 1988, and for $2500 after 
that. Site licenses are available for 
qualified organizations. 
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AI-Net helps build 
neural networks 

A1 Ware offers AI-Net to help users 
build neural networks for specific appli¬ 
cations. 

According to the company, the AI- 
Net Windows Interface permits you to 
prototype a neural net solution to an 
application problem. Implementation 
of the neural net uses the AI-Net 
Accelerator Card and AI-Net Program¬ 
ming Interface. 

AI-Net requires an IBM PC-XT, PC- 
AT, or compatible with 256K bytes of 
RAM; one double-sided, double-density 
floppy disk drive, with hard disk recom¬ 
mended; DOS 2.0 or later; Microsoft C 
for the Programming Interface; and a 
color monitor, EGA card, and mouse 
for the Windows Interface. 

The software includes a Rumelhart 
model, a Hopfield model. Program¬ 
ming Interface with a library of C func¬ 
tions for integrating AI-Net into 
existing systems, Windows Interface 
(requires Microsoft Windows), and 
sample programs. 

Hardware features include the 
Accelerator Card, 32K bytes of data 
RAM and 16K bytes of program RAM, 
variable node capacity, and a reputed 
speed of 11,000 connection updates per 
second. 

A demonstration kit contains 
documentation, sample programs, and 
AI-Net software for limited size net¬ 
works. It requires Microsoft Windows. 
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Apollo extends Ethernet support 


Apollo Computer has extended support 
of Ethernet with the 802.3 Network 
Controller-VME, which reportedly 
allows Apollo’s high-end workstations 
and servers to connect directly to Ether¬ 
net networks. 

The 802.3 Network Controller-VME 
resides in a DN580 or DN590 Turbo 
graphics workstation or DSP500-T 
server equipped with a VMEbus expan¬ 
sion chassis. The controller is compliant 
with IEEE 802.3 and compatible with 


C compiler targets DSPs 

Motorola’s Digital Signal Processor 
Operation has announced the 
DSP56KCC C-language compiler, a full 
Kernighan and Ritchie C implementa¬ 
tion that supports development of 
DSP56000 family applications. 

According to the company, the prod¬ 
uct features compiler assembly language 
efficiency of more than 90 percent, with 
full in-line code capability and a C- 
preprocessor supporting macro expan¬ 
sion, file inclusion, and conditional 
compilation. 

DSPKCC is available on the IBM PC 
for MS-DOS and PC-DOS 
(DSP56KCCA, $709), on the Sun 
Microsystems Sun-3 for Unix BSD 4.2 
(DSP56KCCC, $4709), on the Digital 
Equipment Corp. VAX for VMS Ver¬ 
sion 4.2 (DSP56KCCD, $4709), and on 
the VAX for Unix BSD 4.2 
(DSP56KCCE, $4709). An Apple 
Macintosh II version is planned. 

Motorola has also announced a soft- 


Ethernet Versions 1.0 and 2.0. 

The Turbo graphics workstations and 
DSP500-T servers can accommodate up 
to two Ethernet controllers and one 
Apollo Token Ring controller. Work¬ 
stations and servers can be purchased 
with either controller. 

The 802.3 Network Controller-VME 
can be purchased as an add-on for 
$4000. 
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ware package called DSP56000CLASx 
to facilitate design-in of Motorola’s 
DSPs. The package includes a relocata¬ 
ble assembler, a set of callable simula¬ 
tor modules, a linker, and a simulator 
that supports simulation of multichip or 
single-chip applications. 

DSP56000CLASx is an upgraded ver¬ 
sion of DSP56000SASMx. Registered 
users of its predecessor may purchase 
an upgrade at a reduced price. 

DSP56000CLASA for the IBM PC 
running MS-DOS and PC-DOS costs 
$495. DSP56000CLASC for the Sun 
Microsystems Sun-3 running Unix BSD 
4.2 costs $5500. DSP56000CLASD on 
the DEC VAX running VMS Version 
4.x costs $5500. DSP56000CLASE on 
the DEC VAX running Unix BSD 4.2 
costs $5500. Upgrade parts cost $225, 
$2000, $2000, and $2000, respectively. 

C compiler: Reader Service 47 
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Avatar connects Mac II to IBM mainframes 


Avatar Technologies will offer the 
MacMainframe II, an internal card and 
software package that allows users of 
the Apple Macintosh II computer to 
connect with IBM mainframe com¬ 
puters. The product provides IBM 
3278/79 terminal emulation. 

MacMainframe II supports IBM 
seven-color emulation with user- 
selectable color choices, according to 
Avatar. It also allows text, binary, and 
document file transfer between Macin¬ 
tosh computers and IBM mainframes in 
CICS, TSO, or CMS operating envi¬ 
ronments. 

The product is reportedly compatible 
with Apple’s MultiFinder and IBM’s 
host file transfer module, IND$FILE. 

According to the company, Mac¬ 
Mainframe II allows users to share files 


across existing 3270 networks. The 
document file transfer capability per¬ 
mits use of the host as a storage 
resource, and exchange of information 
such as worksheets. 

The product consists of a Macintosh 
disk and an internal card that plugs into 
the expansion port of the Macintosh II. 
A Type A coaxial cable connects to an 
IBM control unit or Display Printer 
Adapter. An optional Applications Pro¬ 
gram Interface allows software 
developers driver-level access to Ava¬ 
tar’s 3270 terminal emulation and file 
transfer applications. 

MacMainframe II is scheduled for 
release in the second quarter of 1988. 
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LAN costs $199 per network station 


Artisoft, Inc. has announced the 
Netbios-compatible LANtastic local 
area network and LANmark software 
for the IBM PC, PC-XT, PC-AT, PS/2 
Model 30, and compatibles. A version 
for other PS/2 models is planned for 
second quarter 1988, along with an 
SCSI adapter to connect Apple Macin¬ 
tosh computers to the LANtastic 
network. 

The LANtastic starter kit, costing 
$399, consists of two interface cards, 
cable to connect two PCs, two termina¬ 
tion plugs, Netbios software, and LAN¬ 
mark network software. Users can run 
any Netbios-compatible network soft¬ 
ware. Additional LANtastic cards and 
cable cost $199 each. 

LANtastic networks can connect as 
many as 32 computers within 500 to 
1500 feet without a repeater and more 
than 500 over several miles with 
repeaters, according to the company. 
The computers are connected in a bus 
topology by daisy-chaining the output 
of one network station to the input of 
the next. 

The LANtastic card reputedly com¬ 


municates at two megabits per second, 
using synchronous data-link control 
protocols and RS-422 differential 
drivers. The card contains a 
microprocessor running at 10 MHz, 
with 32K bytes of 100-ns on-board dual- 
ported memory. 

The LANtastic networking software 
consists of two parts: LANBIOS, which 
provides the Netbios software drivers 


for the card; and LANmark, a window- 
oriented network operating system for 
loading and running the network. 

LANBIOS takes two to three kilo¬ 
bytes of the PC’s memory. LANmark 
software requires less than 32K bytes 
configured as a server, or less than 15K 
bytes configured as a node. 
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BIOS 286 computer costs $1695 


BIOS Trading Co., Ltd. has 
announced the BIOS Express 286. The 
computer is compatible with the IBM 
PC-AT. 

The Express 286 is designed with a 
10-MHz Intel 80286 processor and one 
megabyte of RAM on the motherboard. 
It comes with eight expansion slots for 
8-bit and 16-bit boards and includes a 
1.2M-byte floppy disk drive, AT-style 


keyboard, real-time clock/calendar with 
battery backup, two serial ports, a par¬ 
allel port, MS-DOS/GW Basic, and a 
15-month warranty. 

The BIOS Express costs $1695. The 
company is seeking distributors and 
dealers. 
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TARGET 
your talent 
search in the 
right direction! 


Find the University personnel you 
need through COMPUTER’S 
classified recruitment pages. 
NEW Closing Dates: regular 
closing is now 1 st of month 
preceding publication date. 


For further information contact: 
Heidi Rex 

The Computer Society of the IEEE 
10662 Los Vaqueros Circle 
Los Alamitos. CA 90720 
[714] 821-8380 



Now you can 
make screens, demos and 
graphics quickly and easily. And improve 
your competitive position at a price you can afford. 

Satisfaction guaranteed or your money back! 

'‘Tremendous productivity tools’' 

(PC Week October27, 1987) 

' 'Many applications will benefit from the quick development times and 
minimal programming required to implement a finished, quality product'' 
(IEEE Software November, 1987) 

“If you want to include bit-mapped graphics in your application, 
then this might be the package for you'' 

(Computer Language June, 1987) 

DisplayExpress T *69 

A fast, efficient and easy-to-use screen manager. 

C-Display Librarian *69 

Professional video, keyboard and graphics functions. 

Send check or money order now to: 

J SYDETECH 

SYSTEM DEVELOPMENT TECHNOLOGIES. INC. 

43-23 COLDEN STREET. #I7C. FLUSHING. N Y. 11355 
For COD orders or the name of the nearest dealer please call (718) 886-0221 
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Telemetry system augmented by computer 


New Mexico State University’s Physi¬ 
cal Science Laboratory has developed a 
portable, computer-augmented teleme¬ 
try system called PC ATS. The system 
consists of three custom printed-circuit 
boards and an integrated software 
package on an IBM PC-AT-compatible 
computer running PC-DOS 3.3 soft¬ 
ware, with a 40M-byte hard disk, 1.2M- 
byte flexible disk, 640K-byte RAM, 
8-MHz 80286 CPU chip, 80287 math 
coprocessor chip, high-resolution color 
monitor, and enhanced graphics 
adapter. 

The system features a PCM bit syn¬ 
chronizer that handles up to 1.8M bits 
per second and 11 common PCM codes, 
a serial time code reader that automati¬ 
cally tags all data, a programmable 
decommutator and disk interface, a 
16-channel digital-to-analog converter, 
a nine-track digital tape drive and con¬ 
troller, a 120M-byte hard disk, a wide- 
carriage printer, and a switched power 
distributor. 

PCATS can reputedly sustain maxi¬ 
mum data logging rates of nearly two 
million bits per second or 100K 16-bit 
data words per second, plus time-tagging 
data. Real-time data are stored on the 
PCATS 120M-byte internal logging 


disk, leaving the PC’s 40M-byte hard 
disk free for other uses. Logged data 
may occupy one or several files readable 
by PC-DOS programs. 

Built-in scaling algorithms include 
linear, discrete, tabular, expression, and 
numeric. A data-table entry assigns a 
set of arguments to a scaling algorithm, 
and a specific scaling algorithm can be 
referenced by any number of data-table 
entries. 

PCATS can display up to 128 sepa- 


HP offers disk drive 

Hewlett-Packard offers the HP 
9153C hard-disk data-storage subsystem 
for HP personal computers, engineering 
workstations, and low-end technical 
systems. 

The desktop disk drive is available in 
four capacities. Three of them—10M, 
20M, and 40M bytes—come standard 
from the factory. The 30M-byte capac¬ 
ity is possible when a user adds the 
20M-byte HP 9153M to the original 
lOM-byte package. The HP 9153M can 
also be placed in the 20M-byte model. 


rate parameters from the real-time data 
stream. Complete display pages are 
typically updated several times per sec¬ 
ond through a process separate from 
data logging. 

The program can generate a variety 
of hardcopy reports, support user- 
formatted reports, and print simple 
data listings for quick-look analysis. 

PCATS retails for $65,000. 
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The three basic capacities can be pur¬ 
chased with an integrated 2M-byte 
(1.42M byte formatted) 3^-inch floppy 
disk drive. 

The HP 9153C costs $1980, $2795, 
and $3640 for the 10M-, 20M-, and 
40M-byte capacities, respectively. 

(Prices include the 2M-byte microfloppy.) 
The 20M-byte stand-alone mechanism, 
HP 9153M, costs $1015. 


RESEARCH MANAGER, 
SOFTWARE 

The Computer Science Division of the Office of Naval Research is seeking a highly qualified individual to plan and manage a program of 
sponsored research in the broad field of software research. The software research program addresses fundamental issues in theory of com¬ 
putation, algorithms, and programming languages including multiparadigm languages, transformational programming techniques, and models 
for reasoning about program verification and validation. This program complements other ONR computer science programs that address 
fundamental issues in parallel and distributed computing, real-time computing, and knowledge representation. The sponsored research is 
conducted principally at universities and industrial laboratories by leading scientists in the field. This is a Civil Service position at the GM-13,14 
or 15 grade level ($38,727-$69,976), depending on individual qualifications. 

The responsibilities for managing the program include recognizing, defining and exploiting new opportunities in software research. The incum¬ 
bent is expected to establish a strong software research program by obtaining, evaluating, and funding high quality research proposals. All Navy 
basic (6.1) research in software is managed within this program. The incumbent maintains close liaison with the ongoing research, monitors 
the results for information of importance to Navy interests, communicates these results to appropriate Navy activities, and manages follow-on 
developmental work. An inherent job satisfaction in the position is obtained through the opportunity to have a creative and significant impact on 
the direction and quality of research conducted at the national level. 

Applicants must have either (1) a Ph.D. or equivalent in computer science, mathematics, electrical engineering or a directly related field and at 
least one year of professional experience or (2) acquired a minimum of three years of progressively responsible professional experience. No 
prior government service is required. Demonstrated research experience is preferred. 

Interested persons should send a list of publications and a Standard Form 171, Application for Federal Employment (available at Federal Job 
Information Centers or from the address below), to: 

OFFICE OF THE CHIEF OF NAVAL RESEARCH 

Civilian Personnel Division, Code 01242P 
ATTN: Announcement #88-02 (1C) 

800 North Quincy Street 
Arlington, VA 22217-5000 

Applications will be accepted through 25 March 1988 and must be received by that date. Applicants are requested to complete the appropriate 
supplemental forms. For further information and supplemental forms, please call (202) 696-4705. 

AN EQUAL OPPORTUNITY EMPLOYER • U.S. CITIZENSHIP REQUIRED 






Call For Papers 


Fifth Workshop 
On 

Real-Time Software and Operating Systems 
May 12-131988 

Omni-Shoreham Hotel, Washington, DC 


Sponsored by 

> The Computer Society of the IEEE 


USENIX Association 


This year’s workshop broadens the scope to include general real-time systems. This workshop will bring 
together researchers, designers, and implementers ot real-time operating systems and software. There 
will be a substantial emphasis on practical experience, so workers from industrial organizations are 
encouraged to attend. Topics of specific interest include: 


Primary requirements of real-time systems 
Distributed real-time operating systems 
Application-specific operating systems 
Practical experiences and implications 
Exotic applications: medicine, music, etc. 
Architectural support for real-time 
Language, programming support, and reusability 
Types of peal-time constraints 
Scheduling and resource management 
Predictability, adaptability, and maintainability 
Reliability and fault tolerance 
Instrumentation and performance measurement 
Case studies 


The format of the workshop will be geared to encourage intense technical interactions and focussed 
discussions. 


Attendance will be limited to between 75 and 100 active workers in the field. To participate in the 
workshop, please submit four copies of an extended abstract or position paper of up to 5 pages 
describing your current efforts to Lui Sha by March 1, 1988. The abstract should focus on insights and 
lessons gained from recent research and practical experience. Complete details regarding the workshop 
will be sent to all participants along with the acceptance letters by March 21, 1988. A digest of accepted 
abstracts will be made available to participants at the workshop. 


General Chair 
Professor John Stankovic 
Department of Computer 
and Information Science 
Graduate Research Center 
University of Massachusetts 
Amherst, MA 01003 
(413) 545-0720 

Csnet: stankovic@cs.umass.edu 


Program Co-chair 
Dr. Marc Donner 
IBM Research 
P.O. Box 218 

Yorktown Heights, NY 10598 

(914) 945-2032 

Csnet: donner@ibm.com 


Program Co-chair 
Dr. Lui Sha 

Computer Science Department 
Carnegie-Mellon University 
Schenley Park 
Pittsburgh, PA 15213 
(412) 268-7668 

ARPANET: sha@k.gp.cs.cmu.edu 
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1C Announcements 


Company, Model, Function Comments R.S. No. 


Analog Devices 

AD7672 

ADC 

A monolithic analog-to-digital converter available in two versions over three temperature 120 

ranges (10 ^ts and 5 pis) and one version over two temperature ranges (3 pis). Features a 

12-bit parallel interface and on-chip clock oscillator. Comes in 28-terminal LCCC and 

PLCC surface-mount, plus 24-pin plastic or ceramic DIP. Cost: starts at $33 (10 prs), $44 (5 
pis), and $75 (3 pis). 

Analog Devices 

AD7228 

DAC 

Features eight 8-bit digital-to-analog converters, bus interface circuitry, and voltage-output 121 
amplifiers. Comes in a 24-pin plastic DIP or hermetic cerdip, 28-terminal PLCC, or lead¬ 
less ceramic chip carrier. Operating temperatures of - 40°C to 85 °C and - 55 °C to 125 °C. 

Cost: starts at $32 (100s) for ±2 LSB and $37 for ±1 LSB. 

Honeywell 

HDAC7542A, 

HDAC7543A, 

A family of 12-bit multiplying digital-to-analog converters. Output capacitances of less 122 

than 75 pf. Settle to within ±/ LSB in 500 ns. HDAC50500 features a microprocessor inter¬ 
face. HDAC7542A and HDAC7543A come in 16-lead plastic or cerdip packages; 


HDAC7545A, HDAC50500 HDAC7545A and HDAC50500 come in 20-lead plastic or cerdip packages. Available over 
DACs three temperature ranges. Cost: starts at $6.59 (100s). 


Honeywell 

HDAC50600 

DAC 

A 14-bit digital-to-analog converter. Includes latches, two reference inputs, a bipolar offset 123 
input, and trimmed applications resistors. Power dissipation of 30 mW; settling time of 

500 ns. Available over industrial and military temperature ranges. A and B grades with ±K 
and 1 LSB linearity, respectively. Cost: starts at $21.85 (100s). 

Hybrid Systems 

HS7584 

DAC 

Features four current-output, 12-bit digital-to-analog converters and a microprocessor 124 

interface. Settling time of 3 /us maximum. Comes in a 40-pin hermetic cerdip or ceramic 
leadless chip carrier. Operating temperature ranges of 0°C to 70°C for C versions and 
- 55 °C to 125 °C for B versions (with Mil-Std-883C screening). Cost: (100s) $62 for C, 

$120 for B. 

Hybrid Systems 

SP1070 

Flash ADC 

A flash analog-to-digital converter containing an 8-bit, 25-MHz A/D, DC-stabilized wide- 125 

band input amplifier, 2.5V reference, and overload protection/recovery circuitry. Comes 
in a 28-pin DIP. Available for 0°C to 70°C operation (C models) or - 55 °C to 125°C oper¬ 
ation (B models, with compliance to Mil-Std-883C). Cost: $350 for C, $450 for B. 

Integrated Device 
Technology 

IDT78C16, IDT78C18 
EEPROMs 

Two 16K EEPROMs featuring a 55-ns read access time. The IDT78C18 also has four pins 126 

that allow read and write functions to be serially performed. The IDT78C16 comes in 

24-pin 300-mil or 600-mil cerdip and 32-pin LCC packages. The IDT78C18 comes in 28-pin 

300-mil sidebrazed DIP and 32-pin LCC packages. Cost: starts at $15 (100s). 

Micro Networks 

MN5295, MN5296 

ADCs 

Two 16-bit analog-to-digital converters with 17-ps maximum conversion time, a double- 127 

wide 32-pin DIP, and optional - 55 °C to 125 °C temperature range and Mil-Std-833 
screening. Also, they pinout their internal reference for external use. Cost: starts at $194 
(100s) for MN5295 and $162 (100s) for MN5296. 

Motorola 

MCM60256 

SRAM 

A static RAM organized as 32K words consisting of eight bits each. Available in speed ver- 128 

sions of 85 ns, 100 ns, and 120 ns, and in low-power versions. Pin compatible with the 2764 

EPROM family. Features two chip-enable pins: an active low signal and an active high sig¬ 
nal. Comes in 28-pin 600-mil DIP. Cost: starts at $18.78 (500s). 

Texas Instruments 
SN74ACT7202 

FIFO 

A low-power IK x 9 first-in, first-out memory. A drop-in replacement for the TI 129 

IDT7202S/L, with pin and function compatibility, but dissipating less power. Available 
with access times of 35 ns and 50 ns maximum. Operates over the 0°C to 70°C range. 

Comes in a 28-pin plastic DIP. Cost: (1000s) $31.25 (35 ns) and $22.50 (50 ns). 

Toshiba America 
TMM24512P 

EPROM 

A 512K one-time programmable EPROM that is programmable with Data I/O’s quick- 130 

pulse algorithm. Organized as 64K x 8. Features an access time of 250 ns and power dissi¬ 
pation of 120 mA operating, 35 mA standby. Pin compatible with the TMM27512D. Oper¬ 
ates over the 0°C to 70°C range. Comes in a 28-pin plastic DIP. Cost: $7.85 (100s). 
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Microsystem Announcements 


Company, Model, Function _ Comments _ R S. No. 


Banyan Systems A 16-bit, AT bus, serial communications, expansion card that supports asynchronous, 

Intelligent Communications block asynchronous, SDLC, HDLC, X.25, and other protocols. Controlled by an 8-MHz 
Adapter Intel 80286 processor with 512K of RAM. Has six communications ports: two DMA 

Communications board channel-controlled lines (speeds up to 64 kps) and four interrupt-driven lines (19.2 kps). 

Cost: $1495. 


DSP Design An interface card to link the IBM PC to the token-passing ARCnet LAN. Can set network 

ARC250 node number by software or switches. Features two kilobytes of dual-ported RAM, net- 

interface card work transceiver circuitry coupled to an isolated ground BNC connector, three byte-wide 

sockets, and two 16-bit timers. No price given. 


GammaLink 
CAD-Fax 
Add-in card 


General Business 
Technology 
GBT 6640 
Printer 


A hardware and software system for the IBM PC, PC-XT, PC-AT, and compatibles. 

Three ways to send or collect design information: facsimile, computer-to-computer file 
transfer, or modem. Uses an HP-GL plot file as input. Automatically divides drawings and 
labels parts for reconstruction upon receipt. Cost: $1995. 

An ion page printer for IBM mainframes. Emulates the IBM 3211 or 3205-5 and provides 
direct channel attach to IBM 9370 and 43XX. Features a print speed of 30 ppm and 
300 x 300 dpi. Outputs in either portrait or landscape format. Includes eight fonts, each 
with 96 characters and 32 graphic characters. Cost: $23,995. 


Imagen 
5320 & 6320 
ImageServer XP 
Laser printers 


New members of the ImageServer XP line of laser printers featuring speeds of 20 ppm, 
support for multiple page description language, and document handling. They consist of a 
laser-based printer marking engine, raster image processor, host/network interface, and 
system software. The 6320 is a duplex printer. Cost: $26,950 for the 5320 and $29,950 for 
the 6320. 


Kentek Information 

Systems 

K-4 

Printer 


A 24-ppm duplex printer with 300 dpi resolution. Comes with one megabyte of RAM and a 
Motorola 68000-based controller. Provides image rotation, text and graphics merge, por¬ 
trait or landscape, and reverse portrait or landscape format. Up to 30 fonts loadable from 
an internal 3^-inch floppy disk. Cost: $19,000. 


Lawrence Technologies 

Datastar 

Modem 


Parsytec GmbH 
BBK-V2 
VME processor 


Qualstar 

Model 1260 GCR 
Streaming tape drive 


Ricoh 
ImageCard 
Fax modem card 


Sharp Electronics 
JX-9300 
Laser printer 


Star Micronics 
NX-1000, NX-1000C 
Multi-Font 
Dot matrix printers 


An internal direct-connect modem for the Zenith 181 and 183 laptop computers. Compati¬ 
ble with Hayes software commands. Selectable baud rates of 300, 1200, and 2400 bps. Fea¬ 
tures nonvolatile storage of modem settings, pulse and tone autodialing, auto-answer, and 
software programmable operating parameters. Cost: $379. 

A transputer for VME systems. Local T800 or T414 processors, equipped with two mega¬ 
bytes of dual-ported RAM accessible by other VME processors or DMA devices. Features 
four link channels at 20M-bits per second. Up to one megabyte of EPROM. Supported by 
Occam and compilers for C, Pascal, and Fortran-77. Cost: 8,900 Deutschmark. 

A compact desktop nine-track tape drive that supports the high-density 6250 bpi GCR 
recording format. Weighs less than 40 pounds. Provides up to 250M bytes of data transfer 
between a PC and host systems. Comes with standard or buffered Pertec interfaces or 
SCSI. Cost: starts at $6975. 

A fax modem card that allows the IBM PC, PC-AT, PC-XT, and compatibles to commu¬ 
nicate with Group 3 and Group 2 facsimile machines. Features automatic dialing, auto¬ 
matic error checking, reports for fax traffic control and management, and automatic 
saving of incoming messages to disk. Comes with PC software. Cost: $1175. 

A 6 ppm compact laser printer with 300 x 300 dpi resolution, 396K memory expandable to 
1.5M bytes, and a Sharp print engine. Targets individual PC users; higher-end models for 
multiple users scheduled. Resident typefaces expandable through downloading or plug-in 
font cartridges. Cost: $2400. 

Nine-wire dot matrix printers. NX-1000 has a parallel interface and incorporates Epson 
and IBM Proprinter II emulations. NX-1000C has Commodore MPS-1000 emulation. 

Both feature 36 cps, draft output of 144 cps, 12 cpi resolution, four internal fonts, and a 
four-kilobyte buffer. Cost: $289 each. 
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Membership Application 


HOW TO JOIN 


Membership dues and publication subscriptions are annualized to December 31. 
Pay the full-year fee if application is mailed September 1-February 29. 

Pay the half-year fee if application is mailed March 1-August 31. 


1 COMPUTER SOCIETY ONLY (affiliate membership). 
You are eligible if you are seriously interested in any aspect of the 
computer field or if you are a member of one of the affiliate 
societies listed below. 

(Check all applicable societies.) 

Affiliate Societies 


Half-Year Full-Year 

P $19.50 □ $39.00 


Astronautics (AIAA) 

□ American Institute of Physics (AIP) 

□ American Mathematical Society (AMS) 

□ American Society of Mechanical Engineers 

□ Association for Computing Machinery (ACM) 

□ Australian Computer Society 

□ British Computer Society 


□ Instrument Society of America (IS 


□ Operations Research Society 

□ Society of Aircraft Materials ar 
(SAM PE) 

□ Society of Automotive Engine* 

□ Society for Industrial and App 
Mathematics (SIAM) 


Dn Processing Society of Japan (IPSJ) 


5 (SAE) 

i (SCS) 


2 COMPUTER SOCIETY AND IEEE.* in addition to your 
Computer Society benefits, you’ll receive many IEEE privileges 
and benefits. You are eligible if your technical interests are in 
computer science and engineering, the electrical and electronics 
fields, or related fields. Your entry membership grade will be 
determined by your level of participation, contributions, education 
and/or experience in those fields. 


Residence 

United States. 

Canada. 

Europe. Africa, Middle East. 

Latin America. 

Asa. Pacific. 


Mar 1-Aug 31 Sept 1-Feb 29 

□ $41.00 □ $82.00 

□ $38.50 □ $77.00 

□ $39.00 □ $78.00 

□ $33.50 □$67.00 

□ $34.50 □ $69.00 


*ACM members who join both IEEE and the Computer Society 
are entitled to a deduction of $5 off the full-year rate; $2.50 off the half-year rate. 


Q COMPUTER SOCIETY MEMBERSHIP FOR 
IEEE MEMBERS. If you are presently an IEEE member, you 
may join the Computer Society for a nominal amount. (Complete 
only shaded area of application.) 

Half-Year Full-Year 
Mar 1-Aug 31 Sept 1-Feb 29 

IEEE Member Number_ □$7.50 □$15.00 


OPTIONAL PUBLICATIONS 


4 Whichever membership option you chose, you are now eligible to 
subscribe at low member rates to these periodicals. 


IEEE Computer Graphics & Applications (3061) 6 

IEEE Design and Test (3111). 6 

IEEE Expert (3151) 4 

IEEE Micro (3071) 6 

IEEE Software (3121). 6 

Transactions on Computers (1161). 12 

Transactions on Pattern Analysis and 

Machine Intelligence (1351). 6 

Transactions on Software Engineering (1171). 12 


□ $9.50 □ $19.00 

□ $10.00 □ $20.00 
□ $6.00 □ $12.00 

□ $9.00 □ $18.00 

□ $8.50 □ $17.00 

□ $9.00 □ $18.00 

□ $7.50 □ $15.00 

□ $ 9.00 □ $18.00 


□ Check or Money Order 
(payable to the IEEE) 

□ Visa Master Card 


TOTAL 


□ American Express 


Credit Card Number 


STUDENTS! ► 


You receive special rates i 
for a student application. 


I benefits. Call or send 






r Computer Society i 


id, if elected, will be governed by IEEE’s and the Society's Constitutions, Bylaws, and Statements 


MAILING ADDRESS 



EDUCATION (highest level completed) 


REFERENCE (a „ 


OCCUPATION 


Residents of Europe 

Computer Society 
of the IEEE 

13, Avenue de t'Aquifon 
B-1200 Brussels, Belgium 
Telephone; 32-2-770-21-98 
Payment to the Brussels 
office may be made by 
cheques in Belgian francs, 
British pounds sterling, 
German marks, Swiss 
francs, or US dollars, or 
by American Express, 
Eurocard, MasterCard, 
or Visa credit cards. 

Computer Society 
of the IEEE 

10662 Los Vaqueros Circle 
Los Alamitos, CA 90720-2578 
Telephone: (714) 821-8380 
Allow six to eight weeks 
for delivery of publications. 































CONFERENCES 


Editor: Edmund L. Gallizzi, Computer Science Dept., Eckerd College, St. Petersburg, FL 33733; (813) 864-8272; Compmail, e.gallizzi 


Fourth Conference on Artificial Intelligence 
Applications set in San Diego 


Impact of standards 
on productivity 
to be addressed at 
Compstan 88 

Compstan 88, the 1988 Conference 
on Computer Standards, will be held 
March 21-23 in the Washington, DC 
area. 

The conference is sponsored by the 
Computer Society in cooperation with 
the technical committees on 
Microprocessors and Microcomputers, 
Computer Communications, Operating 
Systems, Software Engineering, Test 
Technology, and Design Automation, 
as well as the Standards Coordinating 
Committee (SCC). 

Laurel Kaleda of IBM and James 
Hall of the National Bureau of Stan¬ 
dards are co-chairs. 

The conference will serve as a forum 
for discussion of the impact of stan¬ 
dards on the productivity of hardware 
and software and the steps that must be 
taken to insure that standards promote 
productivity rather than stifle progress. 

Howard Yudkin, chief executive offi¬ 
cer of the Software Productivity Con¬ 
sortium, will deliver the keynote 
address on “The Economic Impact and 
Demands that Effect Standards Devel¬ 
opment and Use.” 

The conference will feature selected 
papers and panels focusing on such 
areas as interfaces and environments, 
management of standards, metrics, 
portability, processes, legal implica¬ 
tions, critical applications, the federal 
government’s role in the standards 
process, and the impact of standards on 
the marketplace. 

The SCC will conduct a half-day 
tutorial/workshop on the IEEE stan¬ 
dards development process from 1-5 
p.m. March 23. 

For information about the confer¬ 
ence, contact Kaleda at (408) 284-3026 
or Hall at (301) 975-3273. For informa¬ 
tion on registration, contact Gail Clan¬ 
ton, c/o Computer Society of the IEEE, 
1730 Massachusetts Ave. NW, Wash¬ 
ington, DC 20036-1903; (202) 371-0101. 


Edmund L. Gallizzi, Eckerd College 

The Computer Society will present 
the Fourth IEEE Conference on Artifi¬ 
cial Intelligence Applications (CAIA) 
March 14-18 in San Diego. 

James Miller of MCC is serving as 
general conference chair. 

“CAIA is a conference where system 
builders can find out about important 
applications of AI to real world prob¬ 
lems,” Miller said. 

“We have tried to structure a balance 
between science and engineering and 
choose a program that characterizes 
that balance. We want people to know 
about not only the kinds of systems that 
are being built today, but also the ideas 
and techniques that will be important 
for the applications of the future.” 

Program co-chair Elaine Kant of 
Schlumberger-Doll Research said 2/ 
days of paper and panel sessions and 
invited talks are on the agenda in three 
concurrent tracks. They will start 
March 16, and a keynote address will 
launch each day’s schedule March 16, 
17, and 18. 

Since the event will be applications- 
oriented, the three keynote addresses 
will focus on both current and future 
applications. 

Scott Flaig of Digital Equipment 
Corporation will present the keynote 
talk March 16. Flaig said the speech, 
entitled “The Impact of AI on the Cor¬ 
porate Enterprise, with Special Empha¬ 
sis on Computer Integrated 
Manufacturing,” will be devoted to the 
state of current systems and will deal 
with 

• management’s role in developing 
the business environment so tech¬ 
nology succeeds; 

• the steps his company is taking to 
internally create that environment 
so conventional applications, such 
as CIM (computer-integrated man¬ 
ufacturing), succeed; and 

• the way expert systems have been 


incorporated into manufacturing 
and enterprise environments, such 
as marketing, engineering, and field 
operations, to achieve competitive 
leadership within the computer 
industry. 

The future of AI applications will be 
the subject of the March 17 keynote 
address, “What’s Missing in AI—Can 
Massively Parallel Architectures 
Help?” Scott Fahlman of Carnegie- 
Mellon University will be the speaker. 

According to Fahlman, today’s AI 
technology is valuable but incomplete. 
Some things that are very easy for a 
person to do are still well beyond the 
reach of our current technology, which 
fundamentally takes a serial approach 
based on symbolic reasoning and heu¬ 
ristic search. 

Fahlman’s talk will attempt to 
characterize the gaping holes in our cur¬ 
rent technology and describe some mas¬ 
sively parallel approaches that might be 
capable of filling those holes. 

“Connectionist” or “neural net¬ 
work” systems are among the parallel 
architectures that will be considered. 
Fahlman will look not only at the 
potential of these systems, but at the 
problems that must be solved if that 
potential is to be realized. 

Henry Lum of the NASA-Ames 
Research Center will dedicate his March 
18 keynote talk to applications with an 
important future orientation. His 
remarks are entitled “The NASA Sys¬ 
tem’s Autonomy Program: Applying 
AI in Space.” 

According to Lum, intelligent 
“autonomous” systems are character¬ 
ized by their ability to communicate at 
high levels with humans and other intel¬ 
ligent machines. These systems will be 
able to recognize and correct human- 
induced errors that would inadvertently 
endanger the system or its performance. 
They can operate autonomously for 
extended periods of time and will be 
capable of understanding dynamic 
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Conference keynoter calls for wider availability 
of computer simulation to end-users 

Sallie Sheppard, Texas A&M University 


world environments, arriving at reliable 
decisions in areas of uncertainty, and 
executing command functions required 
for mission success. 

Research thrusts to achieve these 
capabilities center around machine 
learning; coordinated real-time decision 
making via multiple, coordinating intel¬ 
ligent agents; management, main¬ 
tenance, and real-time control of 
distributed databases; software verifica¬ 
tion and validation; and fault-tolerant, 
multiprocessor architectures capable of 
operating in a heterogeneous environ¬ 
ment. Lum will summarize the research 
plans and the progress made in each of 
these areas. 

Invited panel sessions will include 
“AI and CASE: Constructive Conver¬ 
gence,” moderated by Esther Dyson, 
EDventure Holdings; “Expert Systems 
That Didn’t Make It: Why?” moder¬ 
ated by Richard Wexelblat, Philips 
Laboratories; “Is There a Future for 
Lisp Machines?” moderated by Fahl- 
man; and “Integrating AI and Data¬ 
bases: Today’s Capabilities, 
Tomorrow’s Goals,” moderated by Jan 
Aikins, Aion Corporation. 

Two days of tutorials on March 14-15 
will precede the paper sessions. The 
tutorials will include “Managing 
Knowledge System Development,” “AI 
in Manufacturing,” “Knowledge Struc¬ 
turing Techniques for Knowledge 
Acquisition,” “User Interfaces,” “Is 
Natural Language Processing Useful in 
My Applications?” “Introduction to 
Object-Oriented Concepts,” and “A 
Survey of DOD Research and Applica¬ 
tions in AI.” 

For additional conference informa¬ 
tion, contact CAIA, Computer Society 
of the IEEE, 1730 Massachusetts Ave 
NW, Washington, DC 20036-1903; 

(202) 371-1013. 


Keynoting an Atlanta conference, 
John White called for wider availability 
of computer simulation in a provoca¬ 
tively titled address, “Simulation: 
Pushing a Dead Mouse Through a 
Maze?” 

White, a regents’ professor of indus¬ 
trial and systems engineering at the 
Georgia Institute of Technology and an 
executive consultant for Coopers and 
Lybrand’s SysteCon Division, delivered 
the keynote address at the Winter Simu¬ 
lation Conference. 

He explained that the title of his 
address is, in fact, a definition for simu¬ 
lation he once heard. In the talk, he 
questioned each word of the definition, 
suggesting that the technique has 
become much more applicable for sup¬ 
port of designing, training, and operat¬ 
ing complex integrated systems. 

White cautioned against an elitist 
attitude for simulationists, and 
encouraged the development of tools 
and techniques that can make simula¬ 
tion more widely available to the end 
user. He claimed that impediments to 
accessibility need to be identified and 
steps need to be taken to eliminate 
them. Achieving this, he said, will lead 
to increased use and acceptance of 
simulation. 

White’s address set the tone for the 
annual conference, which is designed to 
provide material for the novice as well 
as the advanced practitioner. Chaired 
by Hank Grant of Factrol, the event ran 
over 2/ days in mid-December and fea¬ 
tured 124 papers in seven parallel 


tracks. W. David Kelton of the Univer¬ 
sity of Minnesota was program chair. 

Three tutorial tracks provided infor¬ 
mation on introductory, general soft¬ 
ware, and specific software topics 
relevant to simulation. The modeling 
methodology and manufacturing appli¬ 
cations tracks were the most popular in 
terms of attendance. 

The modeling methodology track 
began with a stimulating panel discus¬ 
sion featuring leading simulationists 
James Henriksen, Richard Nance, 
Dennis Pegden, Charles Standridge, 
and Brian Unger. They previewed the 
simulation environment of the 1990s. 

Other sessions considered specific 
development areas such as visual simu¬ 
lation, object-oriented techniques, arti¬ 
ficial intelligence in simulation, and 
distributed and parallel simulation. 

The popularity of the manufacturing 
applications track provided evidence of 
simulation’s importance as a technique 
in manufacturing systems. Among the 
topics covered were simulation as an 
operations tool, manufacturing model¬ 
ing concepts, artificial intelligence and 
manufacturing simulation, and analyti¬ 
cal and simulation modeling in manu¬ 
facturing. 

The conference is cosponsored by the 
Computer Society’s Technical Commit¬ 
tee on Simulation and seven other 
organizations. This breadth of sponsor¬ 
ship reflects the cross-disciplinary 
nature of computer simulation. 

The next conference in the series will 
be held December 12-14, 1988 in San 
Diego. 


Correction 

The photograph accompanying the 
Compsac 87 report (“Tokyo Compsac 
called most successful in conference’s 
history,” Conferences, December 1987, 
p. 103) incorrectly identified the four 
people in it. The correct names, from 
left to right, are Yutaka Ohno, presi¬ 
dent of the Information Processing 
Society of Japan; Mamoru Mitsugi of 
Fujitsu; Masanori Ozeki, the confer¬ 
ence chair; and Masumi Sakamoto of 
the IPSJ. In the story, Tadahiro 
Sekimoto was incorrectly identified as 
president of the IPSJ; he was the hon¬ 
orary conference chair. Shizuma 
Kojima’s name was also misspelled. We 
regret the errors. 
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THE COMPUTER SOCIETY 
OF THE IEEE 
RICHARD E. MERWIN 
SCHOLARSHIPS 

For Members of Student Branch 
Chapters of the Computer Society 

COMPUTER SOCIETY STUDENT BRANCH CHAPTERS are 
technical subunits of IEEE student branches. They are 
established by petition of those student members who 
desire to be involved in specialized activities in the 
computer field. For more information on establishing a 
student branch chapter write or call the Manager for 
Student Services, IEEE Service Center, 445 Hoes Lane, 
Piscataway, N.J. 08855. (201) 981-0060. 

Four $3,000 scholarships are available for the 1988-89 academic year to eligible undergraduate or graduate 
Computer Society student members who are active leaders in student branch chapters. These scholarships 
are one of the several ways that the Computer Society supports the growth and development of student 
branch chapters. 


DEADLINE: MAY 15, 1988 

WHY? 

To recognize and reward students who are active leaders in their IEEE Computer Society student 
branch chapters and show promise in their academic and professional efforts. 

HOW MUCH? 

The amount of each award is $3,000 for one academic (9 months) year starting in September and 
paid in three quarterly installments (August, December, and April). 

WHO IS ELIGIBLE? 

Graduate students, juniors, and seniors in electrical engineering, computer engineering, computer 
science, or well-defined computer related field of engineering (e.g. biomedical computer engineer¬ 
ing, design automation, etc.) who are active members of the Computer Society student branch 
chapter at their institution are eligible. There are no restrictions on the receipt of other 
scholarships or awards in conjunction with receiving this scholarship. Minimum overall grade point 
average should be 2.5 over 4.0 for all undergraduate course work. The applicant must be enrolled as 
a full-time student as defined by his or her academic institution during the course of the award. 

HOW TO APPLY 

The application form appears on the back of this page. Complete the form carefully and submit it, 
together with an official transcript of all of your course work, to your chapter advisor, who will mail 
these materials along with a personal letter of evaluation. The postmark deadline is May 15, 1988. 
Judging will be done by a broad-based panel of active Computer Society members. The primary 
factors considered are involvement in chapter activities (counts 40%), academic achievement 
(counts 30%), other extracurricular activities in college (counts 10%), and letter of evaluation by 
branch chapter advisor (counts 20%). 

The results of the competition will be announced by August 1,1988 and the recipients will receive 
the first of three equal installments by August 15, 1988, the second by December 15, 1988, and the 
third by April 1, 1989 while a full-time student in good standing. A brief statement will be submitted 
by each winner at the end of the academic year outlining his or her accomplishments. 
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Application for Richard E. Merwin Student Scholarship 


Please type or write plainly in black ink. (One additional page may be included if necessary.) 
Submit this application and official transcripts of all your course work to your chapter Advisor who will 
send it with a personal letter of evaluation by May 15,1988 to: 

The Computer Society Of The IEEE, 

1730 Massachusetts Ave., N.W., Washington, D.C. 20036-1903 
Phone: (202) 371-0101 Telex: 7108250437 IEEE COMPSO 


1) Name:_ Date_ 

Permanent Mailing Address_ 

Current 

_ Telephone_ 

Academic department or program: __ 

Name and address of institution: __ 

Name of your Computer Society Branch Chapter Advisor:_ 

2) Statement of your involvement in Computer Society Chapter activities, operations or projects. (Do not include 
IEEE Student Branch or non-Chapter-related activities here.) 


3) Statement of your intention to continue the present field of study on a full-time basis. 

4) Your overall grade point average_out of a possible_ 

Number of credit hours applied towards degree_ 

Number required for degree_ 

5) Brief summary of other extracurricular activities participated in during years in college (school, civic, sports, 
hobby, or other). 


To the best of my knowledge all information 

provided above is accurate and correct. _ 

Signature of Student Member 























CALL FOR PAPERS 


Call for referees for Computer 


Referees are sought for special issues of 
Computer that will cover the following 

• laser communication technology and 
systems 

• computer-integrated manufacturing 

• national computer policies—the com¬ 
puter industry in an international 
context 

• innovative printer technology 

• storage technology 

• concurrent systems: the hardware, 
production, maintenance, and 
software issues 

• emerging technologies for computer 


component, hardware, and software 
design and production 
high-performance CAD/CAM, 
engineering/scientific, and 
programming workstations 
computers in automobiles 
computers in the entertainment and 
advertising industries 
real-time systems 
Videotex—has the vision failed? 


Persons interested in serving as referees are 
asked to circle No. 195 on the Reader Service 
Card at the back of this magazine and to 
send the card to the Reader Service Inquiries 
Dept. 


IEEE Expert is seeking materials for 
5*7 publication. Submit articles on tech¬ 
nology and AI applications to David Pessel, 
Editor-in-Chief, BP America, 4440 Warrens- 
ville Center Rd„ Cleveland, OH 44128; 
reports on conferences, short subjects and 
papers on PCs, products, and resources to 
Henry Ayling, Managing Editor, IEEE 
Expert, 10662 Los Vaqueros Cir., Los 
Alamitos, CA 90720; and book reviews to 
K.S. Shankar, Associate Editor, Federal Sys¬ 
tems Division, IBM Corp., 3700 Bay Area 
Blvd., Houston, TX 77058. 

Technical Committee on Computer 
5*7 Education, Computer Society of the 
IEEE: Contributions are welcomed for the 
TCCE newsletter, a forum for the exchange 
of ideas among persons interested in com¬ 
puter education or computers in education. 
Submit news items, short articles, and cor¬ 
respondence to Helen Hays, Dept, of Com¬ 
puter Science, Southeast Missouri State 
University, Cape Girardeau, MO 63701; 
(314)651-2244. 

Artificial Intelligence and Education: This 
journal seeks articles and proposals for 
issues devoted to specific topics. Authors in 
the US and Far East should contact Elliott 
Soloway, Dept, of Computer Science, Yale 
University, New Haven, CT 06520. Authors 
in Europe should contact Masoud Yazdani, 
Dept, of Computer Science, Prince of Wales 
Rd., University of Exeter, Exeter EX4 4PT, 
England, UK. 


International Journal of Pattern Recognition 
and Artificial Intelligence: Submit manu¬ 
script to H. Bunke, Universitat Bern, Institut 
fur Informatik und Angewandte Mathema- 
tik, Langgasstrasse 51, CH-3012 Bern, Swit¬ 
zerland; or Patrick Wang, College of 
Computer Science, Northeastern University, 
360 Huntington Ave., Boston, MA 02115; 
(617) 437-3711. 


International Journal of Computer Applica¬ 
tions in Technology begins publication in 
Spring 1988. Submit papers for this 
UNESCO-supported journal to M.A. Dor- 
gham, The Open University, Milton Keynes, 
MK7 6AA, England, UK; phone (44) 
09-08-653-945. 


IEEE Transactions on Reliability: Special 
issue on reliability of parallel and distributed 
computing networks scheduled for publica¬ 
tion in late 1988. Submit contributions to 
Dharma P. Agrawal or Suresh Rai, Dept, of 
Electrical and Computer Engineering, PO 
7911, North Carolina State University, 
Raleigh, NC 27695-7911; (919) 737-2336. 


First International Workshop on 
5^* Transaction Machine Architecture 

(ACM): Sept. 25-28, Lake Arrowhead, 
Calif. Submit paper by Feb. 15, 1988, to 
Dieter Gawlick, Amdahl Corp., MS 213, 
1250 E. Arques Ave., Sunnyvale, CA 
94088-3470; (408) 746-7011. 


ZSN Fifth Workshop on Real-Time Operat- 

'5*7 ing Systems: May 12-13, 1988, Wash¬ 
ington, DC. Submit abstract by Feb. 15, 
1988, to Lui Sha, Computer Science Dept., 
Carnegie Mellon University, Schenley Park, 
Wean Hall, Pittsburgh, PA 15213; (412) 
268-7668. 


l^^jCompsac 88, 12th International Com- 
5*7 puter Software and Applications Con¬ 
ference: Oct. 3-7, 1988, Chicago. Submit 
paper by Feb. 15, 1988, to Wing N. Toy, 
Compsac 88, AT&T Bell Laboratories, Rm. 
1Z-306, 200 Park Plaza, Naperville, IL 
60566; (312)416-4046. 


IFIP Congress 89, 11th World Computer 

Congress: Aug. 28-Sept. 1, 1989, San Fran¬ 
cisco. Submit panel session proposals by 
Feb. 15, 1988, and full papers by Nov. 1, 
1988, to Herve Gallaire, ECRE, Arabellas- 
trasse 17, D-8000 Munich 81, Federal Repub¬ 
lic of Germany; phone 49-89-9269-9100. 


International Conference on Computer 
Graphics: Sept. 15-16, 1988, Singapore. Sub¬ 
mit abstract by Feb. 15, 1988, and full manu¬ 
script by May 31, 1988, to Goh Wee Leng, 
Nanyang Technological Institute, Nanyang 
Avenue, Singapore 2263, Republic of Sin¬ 
gapore. 


Z2N Computational Intelligence 88: Sept. 
'87 26-30, 1988, Milano, Italy. Submit 
paper by Feb. 27, 1988, to Antonio Liverani, 
Centro di Calcoco, Universita di Milano, Via 
Colombo 71, 20133 Milano, Italy; phone 
(39) 02-2361-176 

Z2N ICCL 88, International Conference on 
5*7 Computer Languages: Oct. 9-13, 1988, 
Miami Beach, Fla. Submit paper by Mar. 1, 
1988, to C.V. Ramamoorthy, Dept, of 
EECS, University of California, Berkeley, 
CA 94720. 

Z2N IEEE Transactions on Computers, 
'5*7 December 1988: Papers are sought for 
a special issue devoted to parallel and dis¬ 
tributed algorithms. Guidelines for submit¬ 
tals appear in each issue of IEEETC. 

Submit seven copies of manuscript by Mar. 
1, 1988, to C.L. Liu, Dept, of Computer 
Science, University of Illinois, 1304 W. 
Springfield Ave., Urbana, IL 61801-2987; 
(217)333-6769. 


International Journal for Artificial Intelli¬ 
gence in Engineering: Papers are sought on 
research and development leading to 
problem-solving strategies. For information 
and submission requirements, contact D. 
Sriram, Dept, of Civil Engineering, Carnegie 
Mellon University, Pittsburgh, PA 15213; or 
K.J. MacCallum, Dept, of Ship and Marine 
Technology, Marine Technology Center, 100 
Montrose St., Glasgow, Scotland, UK. 


72^ Conferences that the Computer Society sponsors or participates in are indicated 
'5*7 by the Computer Society logo; additional conference sponsors are listed in paren¬ 
theses. Other conferences of interest to our readers are also included. 

For inclusion in Call for Papers or Calendar, submit information six weeks before 
the month of publication (i.e., for the April 1988 issue, send information for receipt by 
February 15, 1988) to Calendar Editor, Computer, 10662 Los Vaqueros Cir., Los 
Alamitos, CA 90720. 
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CALL FOR PARTICIPATION 

International Workshop on 

DEFECT AND FAULT TOLERANCE 
IN VLSI SYSTEMS 

October 6-7, 1988 

Sheraton - Tara Hotel, Springfield, Massachusetts 

Sponsored by: Technical Committee on Fault-Tolerant Computing 
and Technical Committee on VLSI, IEEE Computer Society 


OBJECTIVE 

Higher densities of VLSI circuits and advanced 
packaging techniques have increased substantia¬ 
lly the need to incorporate defect-tolerance and 
fault-tolerance in the design of the now feasi¬ 
ble complex VLSI and WSI systems. The goals 
of defect-tolerance and fault-tolerance are yield 
enhancement and improvement of reliability, avai¬ 
lability and testability. 

The objective of the workshop is to bring re¬ 
searchers and designers of defect-tolerant and 
fault-tolerant architectures, modeling experts of 
defect, faults, yield and testability together with 
developers of appropriate CAD tools and inno¬ 
vative packaging techniques in order to discuss 
the above mutual goals. 

PROGRAM COMMITTEE 

V. Agarwal, McGill, Canada 
E. Fujiwara, NTT, Japan 

W. Maly, CMU, USA 

E. McCluskey, Stanford, USA 
J. McDonald, RPI, USA 
W. Moore, Oxford, England 
D.K. Pradhan, UMass, USA 
G. Saucier, 1MAG, France 
C.II. Stapper, IBM, USA 

GENERAL CHAIRPERSON 

I. Koren, UMass 
VICE-CHAIRPERSON 
A.D. Singh, UMass 
TOPICS 

The scope of the workshop includes, but is not 
limited to, the following topics: 

• Defect and fault tolerant architectures. 

THE COMPUTER SOCIETY 
^7«0FTHE IEEE 


• Defect and fault tolerant memories. 

• Techniques for yield enchancement. 

• Fault models and defect models. 

• Statistical modeling of defects and yield. 

• Testable designs for VLSI and WSI. 

• Restructuring techniques. 

• Packaging techniques for WSI and 3-D VLSI. 

• High density hybrids. 

• CAD tools. 

• Experimental studies. 

INFORMATION FOR PARTICIPANTS 

Workshop attendance will be limited to allow 
maximum interaction. Each participant should 
submit ten copies of an extended summary (2-3 
pages) of proposed presentation or panel, or a 
brief summary of experience in defect and fault 
tolerant VLSI systems. Original contributions as 
well as review papers will be considered. Submit 
summary by April 5, 1988 to: 

Professor Israel Koren 

Dept, of Electrical &; Computer Engineering 

University of Massachusetts 

Amherst, MA 01003 

Tel: (413) 545-2643 

CSNET address: koren @ umass-ece 

BITNET address: koren @ umaecs 

Notification of acceptance will be posted by June 
1, 1988. Final manuscripts (8-12 pages regu¬ 
lar papers or 4-8 pages short papers, single line 
spacing, including figures) must be received by 
August 1, 1988 to guarantee distribution at the 
workshop. 

Selected contributors will be invited to submit 
their papers (in a camera-ready form) for an 
edited proceeding to be published in a book form 
around March 1989. 







CALENDAR 


February 1988 

Sixth International Symposium on Applied 
Informatics (IASTED), Feb. 16-18, Grindel- 
wald, Switzerland. Contact International 
Assoc, of Science and Technology for Devel¬ 
opment, PO 354, CH-8053, Zurich, Swit¬ 
zerland. 

Second Technology Opportunity Conference 
on Optical Memory Applications, Feb. 

16-18, London. Contact TOC, c/o Roth¬ 
schild Consultants, 256 Laguna Honda 
Blvd., San Francisco, CA 94116-1496; (415) 
681-3700. 

First International Conference on Technol¬ 
ogy Management, Feb. 17-19, Miami, Fla. 
Contact University of Miami Conference 
Center, 400 SE Second Ave., Miami, FL 
33131; (305) 372-0140. 

EPS 88, 1988 Electronic Printing Sys¬ 
tems/Professional Electronic Publishing 
Conference, Feb. 21-25, San Jose, Calif. 
Contact EPS, 1855 E. Vista Way, Suite 1, 
Vista, CA 92084; (619) 758-9460. 

16th ACM Computer Science Conference, 
Feb. 23-25, Atlanta. Contact ACM, 11 W. 
42nd St., New York, NY 10036. 

CSC 88, 16th Annual Computer Science 
Conference (ACM), Feb. 23-25, Atlanta. 
Contact Lucio Chiaraviglio, School of Infor¬ 
mation and Computer Science, Georgia 
Institute of Technology, Atlanta, GA 30332; 
(404) 894-3152. 

Vision Guidance for Robotic Systems 
(SME), Feb. 23-25, Cincinnati. Contact 
Joanne Rogers, Society of Manufacturing 
Engineers, 1 SME Dr., Dearborn, MI 48121; 
(313)271-1500. 

Ontario Research Foundation Seminar and 
Workshop, Feb. 24-25, Toronto, Canada. 
Contact H.G. McAdie, Ontario Research 
Foundation, Sheridan Park Research Com¬ 
munity, Mississauga, Ontario, Canada, L5K 
1B3; phone (416) 822-4111, ext. 534. 


NOMS 88, IEEE 1988 Network Operations 
and Management Symposium, Feb. 28-Mar. 

2, New Orleans. Contact IEEE Communica¬ 
tions Society, 345 E. 47th St., New York, 

NY 10017; (212) 705-7857. 

10th National Computer Conference (IEEE), 
Feb. 28-Mar. 2, Jeddah, Saudi Arabia. Con¬ 
tact Athar Javaid, IEEE, PO 8900, Jeddah 
21492, Saudi Arabia. 

Symposium on Information Systems as a 
Resource to Support Managerial Decision- 
Making, Feb. 29-Mar. 3, Sydney, Australia. 
Contact IFIP, 3 rue de Marche, CH-1204, 
Geneva, Switzerland. 

Compcon Spring 88, 33rd Interna¬ 
tional Conference of the Computer 
Society of the IEEE, Feb. 29-Mar. 4, San 
Francisco. Contact Hasan al-Khatib, Dept, 
of Electrical Engineering and Computer 
Science, Santa Clara University, Santa 
Clara, CA 95053; (408) 554-4485. 


March 1988 


Ninth Conference on EDP Performance and 
Capacity Management, Mar. 7-8, Scottsdale, 
Ariz. Contact Applied Computer Research, 
PO 9280, Phoenix, AZ; (602) 995-5929. 

Second International Conference on 
Computer Workstations, Mar. 7-10, 

Santa Clara, Calif. Contact Patrick Mantey, 
335A Applied Science Bldg., Dept, of Com¬ 
puter Engineering, University of California, 
Santa Cruz, CA 95064; (408) 429-2158. 

Federal Office Systems Expo, Mar. 7-10, 
Washington, DC. Contact NTP, 2111 Eisen¬ 
hower Ave., Suite 400, Alexandria, VA 
22314;(703)683-8500. 

Southcon 88 (IEEE, ERA), Mar. 8-10, 
Orlando, Fla. Contact Southcon 88, 8110 
Airport Blvd., Los Angeles, CA 90045; (213) 
772-2965. 


SIGCSE Symposium (ACM), Feb. 25-26, 
Atlanta. Contact ACM, 11 W. 42nd St., 

New York, NY 10036. 

Usicon 88, Third User System Interface Con¬ 
ference, Feb. 26-27, Austin, Texas. Contact 
M. Sury, T4-30, or R. Hockenberger, T2-45, 
Bldg. 30E, Lockheed Austin Division, PO 
17100, Austin, TX 78760; (512) 448-5314 or 
5858. 


1988 IEEE Workshop on VLSI, Feb. 
28-Mar. 2, Clearwater Beach, Fla. 
Contact Barbara Matus, Electrical Engineer¬ 
ing Dept., University of South Florida, 
Tampa, FL 33620; (813) 974-2369. 


1988 International Zurich Seminar on 
Digital Communications, Mar. 8-11, 

Zurich. Contact Secretariat IZS 88, c/o P. 
Gunzburger, Hasler AG, TDS, Belpstrasse 
23, CH-3000 Bern 14, Switzerland; phone 41 
(31)632-808. 


1988 International Development Center Con¬ 
ference (DCI), Mar. 13-16, Orlando, Fla. 
Contact Development Center Institute, PO 
44087, Indianapolis, IN 46244-0087; (317) 
846-2753. 


Sixth National Conference on Ada Technol¬ 
ogy, Mar. 14-17, Washington, DC. Contact 
A1 Rodriguez, US Army Communications- 


Electronics Command, AMSEL-RD-LC- 
ASST-1A, Fort Monmouth, NJ 07703; (201) 
532-4725. 


CAIA 88, Fourth International Con- 
^57 ference on Artificial Intelligence Appli¬ 
cations, Mar. 14-18, San Diego. Contact Jim 
Miller, MCC, Human Interface Program, 
3500 W. Balcones Center Dr., Austin, TX 
78720; (512) 338-3342, or CAIA 88, Com¬ 
puter Society of the IEEE, 1730 Mas¬ 
sachusetts Ave., NW, Washington, DC 
20036-1903; (202) 371-1013. 


International Conference Extending Data 
Base Technology (AICA, AFCET, BCS), 
Mar. 14-18, Venice, Italy. Contact Joachim 
W. Schmidt, Universitat Frankfurt, Fach- 
bereich Informatik, Dantestrasse 9, D6000 
Frankfurt 1, West Germany; phone (49) 
69-798-8101. 


Securicom 88, Sixth Worldwide Congress on 
Computer and Communications Security 
and Protection, Mar. 15-17, Paris. Contact 
Securicom 88, 8, rue de la Michodiere, 75002 
Paris, France; phone (33) 1-47-424-100. 

Seventh IEEE Phoenix Conference on Com¬ 
puters and Communications, Mar. 16-18, 

Scottsdale, Ariz. Contact Carl Ryan, Mo¬ 
torola GEG, 2501 S. Price Rd., Chandler, 
AZ 85248-2899; (602) 732-3074. 

21st Simulation Symposium (SCS, IMACS), 
Mar. 16-18, Tampa, Fla. Contact Alfred 
Jones, Computer Science Dept., Florida 
Atlantic University, Boca Raton, FL 33431; 
(305) 393-3675. 


Western Educational Computing Workshops 
(CECC), Mar. 17-18, Norwalk, Calif. Con¬ 
tact Alexia Devlin, San Francisco State Uni¬ 
versity, Accounting Data, NADM-358, 1600 
Holloway Ave., San Francisco, CA 94132. 

11th PACS Computer Festival, Mar. 19, 

Philadelphia, Pa. Contact Stephen A. 

Longo, Philadelphia Area Computer Soci¬ 
ety, c/o La Salle University, Philadelphia, 
PA 19141; (215) 951-1255. 


20th Southeastern Symposium on Sys- 
^§7 tem Theory, Mar. 20-22, Charlotte, 
N.C. Contact William A. Smith, Dept, of 
Electrical Engineering, University of North 
Carolina, Charlotte, NC 28223; (704) 
547-4142. 


NCGA 88, Ninth Conference and Exposition 
on Computer Graphics Applications, Mar. 
20-24, Anaheim, Calif. Contact NCGA 88, 
National Computer Graphics Assoc., 2722 
Merrilee Dr., Suite 200, Fairfax, VA 22031. 


Compstan 88, Computer Standards 
'5g7 Conference, Mar. 21-23, Arlington, 
Va. Contact James Hall, US Dept, of Com¬ 
merce, National Bureau of Standards, Tech- 
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nology Bldg. 225, Rm. B266, Gaithersburg, 
MD 20899; (301)975-3273. 

RIAO 88, User-Oriented Content-Based Text 
and Image Handling Conference (AFIPS), 
Mar. 21-24, Cambridge, Mass. Contact 
RIAO 88 Conference Service Office, Mas¬ 
sachusetts Institute of Technology, Bldg. 7, 
Rm. 111, Cambridge, MA 02139; or CID, 36 
bis, rue Ballu, 75009 Paris, France. 

Sixth IEEE VLSI Test Workshop, 

Mar. 22-23, Atlantic City, N.J. Con¬ 
tact Wesley E. Radcliffe, IBM East Fishkill, 
Dept. 277, Bldg. 321-5E1, Hopewell Junc¬ 
tion, NY 12533; (914) 894-4346. 


of Tennessee, ECE, Ferris Hall, Knox¬ 
ville, TN 37996-2100; (615) 974-5450. 

Conference on the Human Dimension in 
Artificial Intelligence, Apr. 6-9, Lexington, 
Ky. Contact Engineering Continuing Educa¬ 
tion, 223 Transportation Research Bldg., 
University of Kentucky, Lexington, KY 
40506-0043; (606) 257-4295. 

International Workshop on Robot Control: 
Theory and Applications (IEE), Apr. 11-12, 

Oxford, England. Contact the Computing 
and Control Division, IEE, Savoy PL, Lon¬ 
don WC2R 0BL; phone 44 (01) 240-1871, 
ext. 330. 


AAAI Spring Symposium, Mar. 22-24, Palo 
Alto, Calif. Contact American Assoc, for 
Artificial Intelligence, 445 Burgess Dr., 
Menlo Park, CA 94025-3496; (415) 

328-3123. 

BANKAI 88 (SWIFT), Mar. 22-24, London. 
Contact Jean Steinier, Society for World¬ 
wide Interbank Financial Telecommunica¬ 
tions, PO 2005, Culpeper, VA 22701; (703) 
829-1300. 


£3^ Computer Networking Symposium, 
^5? Apr. 11-13, Washington, DC. Contact 
George K. Chang, Bell Communications and 
Research, 6 Colbert PL, Piscataway, NJ 
08854; (201) 699-3879. 

CompEuro 88, Apr. 11-15, Brussels. 

Contact Jacques Tiberghien, VRIJE 
Universiteit Brussels, Pleinlaan 2, 1050 Brus¬ 
sels, Belgium; phone 32 (02) 641-2905. 


CAE India 88, India Computer Graphics 
International Conference and Exhibition, 
Mar. 22-25, New Delhi, India. Contact Tara 
S. Ganguli, Technology and Research 
Associates, 5 Lindsay St., Calcutta 700087, 
India; phone (033) 299-420. 


ICSE 88, 10th International Confer¬ 
ence on Software Engineering (ACM), 
Apr. 11-15, Raffles City, Singapore. Contact 
Tan Chin Nam or Lim Swee Say, 71 Science 
Park, Singapore 0511; phone (65) 772-0200. 


COIS 88, Conference on Office Infor¬ 
ms? mation Systems (ACM), Mar. 23-25, 
Palo Alto, Calif. Contact Robert Allen, 
2A-367, Bell Communications Research, 
Morristown, NJ 07960; (201) 829-4315. 

© Extending Database Technology (IASI, 
1NRIA), Mar. 23-25, Venice, Italy. 
Contact Stefano Ceri, Politecnico di Milano, 
Dipart, di Elektronika, Piazza Leonardo da 
Vinci 32, 20133 Milano, Italy; phone 39 (02) 
236-7241. 

Built-In Self-Test Workshop, Mar. 

23-25, Charleston, S.C. Contact 
Richard Sedmak, Self-Test Services, 6 Lin- 
denwold Ter., Ambler, PA 19002; (215) 
628-9700 or 2106. 

Fourth International Conference on Pattern 
Recognition (BPRA, IAPR), Mar. 28-30, 

Cambridge, England. Contact J. Kittler, 
Dept, of Electronic and Electrical Engineer¬ 
ing, University of Surrey, Guildford GU2 
5XH, England, UK. 


Infocom 88, Conference oi 
v57 Communications, Mar. 28-31, New 

Orleans. Contact Infocom 88, c/o Ron Rut¬ 
ledge, Martin Marietta Energy Systems, MS 
271, Bldg. 4500N, Oakridge National 
Laboratories, PO X, Oakridge, TN 37831; 
(615)625-7643. 

April 1988 

® Applications of Artificial Intelli¬ 
gence VI, Apr. 4-6, Orlando, Fla. 
Contact Mohan M. Trivedi, University 


IPC 88, 17th International Programmable 
Controllers Conference (ESD, SMI), Apr. 
12-14, Detroit. Contact IPC 88, 100 Farns¬ 
worth, Detroit, MI 48202; (800) 457-9504. 

29th Electronics Representatives Assoc. Con¬ 
ference, Apr. 13-18 , Washington, DC. Con¬ 
tact ERA, 20 E. Huron St., Chicago, IL 
60611; (312)649-1333. 


VHDL Users’ Workshop, Apr. 17-20 , 

Charlottesville, Va. Contact Ron Wax- 
man, University of Virginia, Thornton Hall, 
Charlottesville, VA 22901. 

1988 IEEE Symposium on Security and 
Privacy, Apr. 18-21, Oakland, Calif. 
Contact Dave Bailey, US Dept, of Energy, 
Production Operations Division/CIM 
Office, PO 5400, Albuquerque, NM 87115; 
(505) 846-4600. 


Eastern Simulation Conference (SCS), Apr. 
18-21, Orlando, Fla. Contact Society for 
Computer Simulation, PO 17900, San 
Diego, CA 92117; (619) 277-3888. 


Workshop on Factory Communica- 
tions, Apr. 19-20 , Gaithersburg, Md. 
Contact Alfred C. Weaver, Dept, of Com¬ 
puter Science, University of Virginia, Char¬ 
lottesville, VA 22903; (804) 979-7529. 


11th IEEE Workshop on Design for 
N57 Testability, Apr. 19-22, Vail, Colo. 
Contact T.W. Williams, IBM Corp., PO 
1900, Dept. 67A/021, Boulder, CO 80301- 
9191; (303) 924-7692. 


CAREER 


RATES: $12.00 per line, $120 minimum charge 
(up to ten lines). Average six typeset words 
per line, nine lines per column inch. Add $10 
tor box number. Send copy at least one 
month prior to publication to: Heidi Rex or 
Marian Tibayan, Classified Advertising, 
COMPUTER Magazine, 10662 Los Vaqueros 
Circle, Los Alamitos, CA 90720; (714) 
821-8380. 

In order to conform to the Age Discrimina¬ 
tion in Employment Act and to discourage 
age discrimination, COMPUTER may reject 
any advertisement containing any of these 
phrases or similar ones: “...recent college 
grads...,” “...1-4 years maximum experi¬ 
ence...," "...up to 5 years experience...," or 
“...10 years maximum experience." COM¬ 
PUTER reserves the right to append to any 
advertisement, without specific notice to the 
advertiser, “Experience ranges are sug¬ 
gested minimum requirements, not maxi- 
mums.” COMPUTER assumes that, since 
advertisers have been notified of this policy 
in advance, they agree that any experience 
requirements, whether stated as ranges or 
otherwise, will be construed by the reader as 
minimum requirements only. 


THE JOHNS HOPKINS UNIVERSITY 
Department of Computer Science 

The Department of Computer Science in the 
G.W.C. Whiting School of Engineering of The 
Johns Hopkins University is continuing with its 
planned development. Last year five new faculty 
members joined the department. During the cur¬ 
rent academic year further growth is envisioned 
to represent the University in the field of com¬ 
puter science and engineering according to Hop¬ 
kins’ traditional standards of research and teach¬ 
ing of the highest rank. The department will 
move into its new building in early 1988. Addi¬ 
tional faculty are being sought at ail professorial 
levels with research and teaching interests in 
computer systems, programming, languages, and 
artificial intelligence. Senior candidates should 
have an outstanding record of research achieve¬ 
ment; junior candidates should exhibit superior 
research potential. Although the teaching load is 
moderate, genuine commitment to teaching ex¬ 
cellent graduates and undergraduates is also 
necessary. 

Regarding the artificial intelligence area, 
Hopkins' recently formed Mind-Brain Institute 
together with the Center for Cognitive Sciences 
lead a list of University enterprises with which 
faculty in the Department of Computer Science 
can interact while developing an Al program 
within the department itself. Given such broad 
University interest and commitment, the oppor¬ 
tunities and challenges are immense and, quite 
possibly, unprecedented. Candidates with re¬ 
search and teaching interests in the artificial intel¬ 
ligence area should be acutely aware of the foun¬ 
dational positions for which they are applying. 
Applicants should send a resume and the names 
of at least three references to: Professor Gerald 
M. Masson, Department of Computer Science, 
The Johns Hopkins University, Baltimore, MD 
21218 [phone: (301) 338-8577], The Johns Hop¬ 
kins University is an equal opportunity, affir¬ 
mative action employer. 
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OPPORTUNITIES 


GEORGIA INSTITUTE OF TECHNOLOGY 
School of Information and Computer Science 

The School of Information and Computer 
Science invites applications for faculty posi¬ 
tions at all levels. Applicants should have a com¬ 
mitment to teaching and a record of outstanding 
research accomplishments. Applicants who ex¬ 
pect to receive a Ph.D. degree by Fall 1988 and 
who show high potential for research as well as a 
commitment to teaching are also invited. 

The School seeks applicants to strengthen its 
capabilities in all areas of current research ac¬ 
tivity, especially artificial intelligence, software 
engineering, distributed computer systems, and 
also in computer graphics, programming lan¬ 
guages, theoretical computer science, human 
factors, VLSI systems, data communications 
and computer networks, database systems, and 
computer architecture. Very competitive sala¬ 
ries are offered. 

The School has 27 faculty members and antici¬ 
pates further faculty growth. Its educational 
activities include an undergraduate program ac¬ 
credited by the Computing Sciences Accredita¬ 
tion Board, Inc., a Masters program with 150 
students and a Ph.D. program with over 70 
students. Well equipped laboratories support 
research and education. For instance, a recently 
established programming laboratory features a 
network of twenty-four Unix-based workstations. 
High-speed local area networks interconnect all 
major campus laboratories and provide access 
to national newtworks. 

The School has been named a 1987 recipient of a 
five year Coordinated Experimental Research 
grant from the National Science Foundation. 
This grant will fund acquisition of hardware and 
development of software to support experimen¬ 
tal work in parallel and distributed computing. 
Georgia Tech is located in Atlanta, which ex¬ 
periences a mild sunbelt climate. It is the center 
of commerce in the Southeast, offering a diverse 
economy and good employment opportunities in 
all professional areas. Atlanta offers good 
cultural and recreational opportunities, extreme¬ 
ly attractive residential neighborhoods, and af¬ 
fordable housing. 

Candidates should send complete resumes and 
names of at least three references to: Professor 
Richard J. LeBlanc; Chairman, Faculty Search 
Committee; School of Information and Com¬ 
puter Science; Georgia Institute of Technology; 
Atlanta, Georgia 30332. 

Georgia Tech is an equal opportunity employer. 


PRINCETON UNIVERSITY 
Research Associate and Post-DOC 

One or more research positions available im¬ 
mediately under several sponsored projects. The 
projects involve faculty, researchers and 
students, and cover the areas of databases,, 
distributed systems, VLSI design, artificial in¬ 
telligence, and computer architecture. Respon¬ 
sibilities include the design and implementation 
of software systems as well as their experimen¬ 
tal evaluation. Ph.D with experience in at least 
one of the above areas is required. Salary open. 
Send resume to: 

Hector Garcia-Molina 
Department of Computer Science 
Princeton University 
Princeton, N.J. 08544 

An affirmative action/equal opportunity employer. 


WRIGHT STATE UNIVERSITY 
Computer Science & Engineering 

Applicants are invited for full-time positions in 
Computer Science and/or Computer Engineer¬ 
ing at all faculty levels. There is particular in¬ 
terest in professors who have sufficient ex¬ 
perience, currency, and depth to direct doctoral 
students and research dissertations in a PhD 
program in Computer Science & Engineering. 
The Department is also interested in PhD’s with 
less experience, but who have a commitment to 
research and teaching in a PhD granting pro¬ 
gram. Rank and competitive salaries are deter¬ 
mined by qualifications and experience. 

The State supported university is located in a 
high technology environment among industrial/ 
military research and development facilities. An 
associated State assisted research park foster¬ 
ing basic and applied industrial/military/univer¬ 
sity research is active and growing impressively. 
The University has identified computer science 
& computer engineering as an area of high priority 
for continued development. 

Department strenghts include a large faculty, ex¬ 
tensive laboratory facilities, research programs, 
industrial/military support, degree programs in 
both computer science and computer engineer¬ 
ing, and large student populations at graduate as 
well as undergraduate levels. 

Successful candidates for tenure-track posi¬ 
tions should have a Ph.D in Computer Science, 
Computer Engineering, or equivalent back¬ 
ground, and have demonstrated a strong re¬ 
search, as well as teaching, commitment. Any 
non-tenure-track positions will be filled by can¬ 
didates with strong computer science or com¬ 
puter engineering credentials. At least a Master 
of Science Degree in the field is desired. 
Please submit detailed resumes including 
names of 3 references to: Professor Larry A. 
Crum, Chair, Department of Computer Science, 
Wright State University, Dayton, Ohio 45435. 
Reviewing for tenure-track positions will begin 
October 1, 1987 and for non-tenure-track posi¬ 
tions on March 1,1988. Reviewing will continue 
monthly until positions are filled or until Septem¬ 
ber 1, 1988. 

An equal opportunity/affirmative action 
employer. 


CITY COLLEGE OF CUNY 
Faculty Positions 

Applications are invited for anticipated tenure- 
track in the Department of Electrical Engineer¬ 
ing. Applicants should possess a Ph.D and have 
a strong commitment to teaching and research. 
Candidates should have experience in at least 1 
of the following three areas: Computer Engineer¬ 
ing, Signals and Systems (Power, Control, Com¬ 
munications, Signal and Image Processing, Ro¬ 
botics) and electrophysics (Microwave, Optics 
and Lasers). An outstanding research reputation 
with an ability to attract external funding for 
senior positions, or a demonstrated research po¬ 
tential for junior positions, is desirable. Rank 
and salary are open. Applications, including re¬ 
cent publications and research interest, names 
of three professional references should be sent 
by April 15, 1988 to: Faculty Search Committee, 
Department of Electrical Engineering, The City 
College of CUNY, Convent Avenue at 138th 
Street, New York, NY 10031. (212) 6904248/49. 
An AA/EO Employer M/F. 


Education Program Staff Opening: 

Senior Computer Scientist 

The Software Engineering Institute (SEI) is a 
federally funded research and development 
center operated by Carnegie Mellon University 
under contract to the Department of Defense. 
The SEI’s objective is to provide leadership in 
software engineering and in the transition of new 
software engineering technology into practice. 
The SEI Education Program has a staff opening 
for a Senior Computer Scientist to support the 
Graduate Curriculum Project, Undergraduate 
Software Engineering Education Project, and 
Academic Affiliates Program. 

General Qualifications 

Candidates for this position should have an 
understanding of education and the university 
environment we are trying to serve, as well as an 
understanding of computer science and soft¬ 
ware engineering. University teaching experi¬ 
ence is required. Candidates must have a com¬ 
mitment to high quality innovative education so 
that they, along with other senior technical staff, 
may participate in planning the overall SEI 
educational strategy. 

Responsibilities 

This staff member will have responsibility for 
coordinating the various activities through 
which the Education Program interacts with the 
educational community. These activities include: 

• Promoting the Use of SEI Educational 
Materials 

The Education Program produces a variety 
of educational materials, including curri¬ 
culum modules, module support materials, 
books and monographs, and software tools. 
This staff member will manage the pro¬ 
cesses by which these materials are dis¬ 
seminated, including tracking their use and 
soliciting cooperation from educators in the 
creation of new materials. In particular, this 
will include managing the collection, devel¬ 
opment, and dissemination of classroom 
materials for all levels of software engineer¬ 
ing education. 

• Coordinating Academic Affiliate Activities 
This staff member will develop and execute 
plans for activities with the Academic Af¬ 
filiates of the SEI. This includes soliciting, 
reviewing, and summarizing the annual 
reports from affiliates, assisting affiliates 
with curriculum development and insertion 
efforts, and promoting summer and sabbati¬ 
cal visits to the SEI by affiliated faculty. 

• Organizing Education Program Conferences 
and Workshops 

Currently the Education Program conducts 
two Faculty Development Workshops and 
the SEI Conference on Software Engineer¬ 
ing Education annually. This staff member 
will have primary responsibility for planning 
these events, evaluating their effectiveness, 
and improving them. 

Further Information 
Contact: 

Dr. Norman E. Gibbs, Director of Education 
Software Engineering Institute 
Carnegie Mellon University 
Pittsburgh, PA 15213 
(412) 268-7703 

ArpaNet: gibbs@SEI.CMU.EDU 
The Software Engineering Institute is sponsored 
by the Department of Defense. Carnegie Mellon 
University is an equal opportunitylaffirmative ac¬ 
tion employer. U.S. citizenship or resident alien 
status is required. 
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OREGON STATE UNIVERSITY 
Department of Computer Science 

The Department of Computer Science invites 
qualified applicants for two graduate fellow¬ 
ships in Computer Science at Oregon State Uni¬ 
versity. These will begin with the Fall Quarter of 
1988 and will carry a stipend of $10,000 per year. 
Recipients will be selected on a competitive 
basis, with undergraduate performance, scores 
on the Graduate Record Examination, and refer¬ 
ences as the primary source of information. We 
expect that recipients will enroll in the Ph.D. pro¬ 
gram in Computer Science at OSU and will devote 
their full time toward the pursuit of that degree. 
For further information and for application mate¬ 
rials, please contact 

Walter G. Rudd, Chairman 
Department of Computer Science 
Oregon State University 
Corvallis, Oregon 97331 
503-754-3273 

Oregon State University is an Affirmative Ac¬ 
tion/Equal Opportunities employer and complies 
with Section 504 of the Rehabilitation Act of 
1973. 


LOUISIANA STATE UNIVERSITY 
Computer Faculty Positions 

The Department of Electrical and Computer 
Engineering at LSU invites applications for an¬ 
ticipated tenure-track and visiting faculty posi¬ 
tions available August 1988 in all areas of com¬ 
puter engineering, including microprocessors, 
distributed processing systems and special pur¬ 
pose architectures. A Ph.D. or equivalent and 
potential for excellence in teaching and research 
are necessary. Rank is open. Salary is com¬ 
petitive and commensurate with qualifications 
and experience. Release time and resources are 
provided in order to enhance the development of 
a quality research program. Opportunities for 
summer support are available. Send resume, 
names of three references, verification of 
employment eligibility in compliance with the 
new Immigration Reform and Control Act, and a 
statement of teaching and research interests to: 
Alan H. Marshak, Chairman, Electrical and Com¬ 
puter Engineering, Louisiana State University, 
Baton Rouge, LA 70803-5901. LSU is an Equal 
Opportunity Employer. 


NORTH TEXAS STATE UNIVERSITY 
COLLEGE OF ARTS AND SCIENCES 
Department of Computer Sciences 

The Department invites applications for tenure- 
track faculty positions at the rank of assistant 
professor, pending budgetary approval, in all 
areas of computer science. A Ph.D. in computer 
science or a related field and evidence of a 
strong commitment to research and teaching are 
required. Salary is competitive. In an exceptional 
case, the position may be filled at a more senior 
level. 

This growing department offers BS/MS/Ph.D. 
programs to approximately 800 undergraduate 
and 250 graduate majors. North Texas State 
University is an emerging national research in¬ 
stitution with excellent facilities to support both 
research and instruction in the vibrant and rapid¬ 
ly expanding Dallas-Fort Worth metropolitan 
area with over 700 regular faculty and over 22,000 
students (one third graduate students). 
Applicants should submit their resumes, in¬ 
cluding the names of three references, to R.T. 
Jacob, Search Committee Chairman, Depart¬ 
ment of Computer Sciences, P.O. Box 13886, 
North Texas State University, Denton, Texas 
76203. 

NTSU is an Affirmative Action/Equal Opportunity 
Employer. 


WORCESTER POLYTECHNIC INSTITUTE 

The Computer Science Department invites appli¬ 
cations for tenure track faculty positions at all 
levels from candidates in ail areas of specializa¬ 
tion. Candidates should have a Ph.D. in Com¬ 
puter Science and a strong interest in both re¬ 
search and teaching. 

Worcester Polytechnic Institute emphasizes 
quality in the undergraduate learning experience 
and is committed to an innovative project- 
oriented teaching environment. The quality of 
the undergraduate computer science degree has 
been recognized by the recent granting of ac¬ 
creditation by the Computer Sciences Accredita¬ 
tion Board. 

The current goal of the Institute is to enhance 
our graduate program and improve research ac¬ 
tivities. The department seeks qualified can¬ 
didates who will help us achieve these objec¬ 
tives. WPI is located close to the center of 
Massachusetts’ minicomputer industry and ex¬ 
cellent opportunities exist for cooperative re¬ 
search and consulting. 

The Department has 12 full-time faculty with 200 
undergraduates and 50 full-time and 120 part- 
time graduate students in our M.S. and Ph.D. pro¬ 
grams. Department equipment includes 4 VAX 
750's, an AT&T 3B-15, 3 Sun Workstations, and 
over 80 PCs (both UNIX and MS-DOS based). 
Much of this equipment is networked via two 
ethernet cables and is also connected to other 
campus facilities, which include a DEC 2060 and 
numerous VAXen. The Institute is committed to 
a new Information Science building and full cam¬ 
pus networking facilities in the near future. 
Located only 45 miles from Boston, Worcester is 
a small city of 180,000 which has recently under¬ 
gone a renaissance. It has eight colleges and 
universities and a rich variety of cultural 
activities. 

Please send a resume to Karen Lemone, Acting 
Department Head, Department of Computer Sci¬ 
ence, WPI, Worcester, MA 01609. 

WPI is an Equal Opportunity/Affirmative Action 
Employer. 


GEORGE WASHINGTON UNIVERSITY 
TENURE-TRACK 
FACULTY POSITIONS 

The Department of Electrical Engineering and 
Computer Science invites applications for 
tenure-track faculty positions in Electrical 
Engineering and Computer Science. Candidates 
should have an earned doctorate and research 
experience, with an interest in both teaching and 
research. Ability to attract research grants and 
contracts for support of faculty and student 
assistants is valued. The George Washington 
University is located in the center of Washing¬ 
ton, DC. This metropolitan area sustains the sec¬ 
ond largest concentration of research and devel¬ 
opment activity in the United States which creates 
a continuing demand for rigorously trained engi¬ 
neers as well as broad research opportunities. Our 
department is the largest department in the 
School of Engineering and Applied Sciences 
with 37 full-time faculty, and a large graduate and 
undergraduate student body. The department 
has an annual research budget of close to $1 
million. Send Curriculum Vita, list of publica¬ 
tions and references, to: 

Professor Roger H. Lang, Chairman 
Department of Electrical Engineering and 
Computer Science 

School of Engineering & Applied Sciences 
THE GEORGE WASHINGTON UNIVERSITY 
Washington, DC 20052 

The George Washington University is an affir¬ 
mative action/equal opportunity employer. 


UNIVERSITY OF ALABAMA AT BIRMINGHAM 

Tenure-track positions in Computer and Informa¬ 
tion Sciences. The Department administers 
degree programs at the B.S., M.S. and Ph.D. 
levels and has a laboratory including a 30- 
processor Sequent Balance 21000, 6 Sun work¬ 
stations, a VAX11/750, a Microvax II and access 
to the new Alabama supercomputer, a Cray XMP. 
Departmental research includes parallel pro¬ 
cessing, neural computing, expert systems, 
simulation, natural language processing, soft¬ 
ware development, compilers, programming lan¬ 
guages, logic programming, scientific comput¬ 
ing and biomedical applications. Applicants for 
senior positions should have an established 
research record. The Department has established 
a collaborative relationship with Ibaraki Universi¬ 
ty in Japan, which includes a three-year faculty 
exchange program funded by the Japanese gov¬ 
ernment. Interested persons should contact Dr. 
Warren T. Jones, Department of Computer and 
Information Sciences, UAB, Birmingham, Ala¬ 
bama 35294. 

UAB is an Affirmative Action/Equal Opportunity 
Employer. 


THE UNIVERSITY OF TENNESSEE 
SPACE INSTITUTE 

Faculty Positions in Computer Science 

Applications are invited for tenure track posi¬ 
tions at all levels. A Ph.D. in computer science or 
a closely related area and a commitment to re¬ 
search and teaching are required. Candidates 
from all areas of computer science will be con¬ 
sidered; however, preference will be given to 
candidates with expertise in artificial intelli¬ 
gence or robotics. UTSI offers M.S. and Ph.D. 
degrees in computer science with emphasis on 
applied artificial intelligence, expert systems 
and robotics. 

UTSI is a multidisciplinary graduate institute of¬ 
fering degree programs and research in engi¬ 
neering, physics, applied mathematics and com¬ 
puter science. Emphasis is placed on research 
and graduate-level instruction. In addition to a 
VAX/780 and VAX/785, two Symbolics 3600 Lisp 
machines are available for research as well as 
linkages to computers at The University of Ten¬ 
nessee in Knoxville and supercomputers at vari¬ 
ous locations. 

Rank and salaries for these positions are open 
and commensurate with qualifications. Fringe 
benefits include group life and medical in¬ 
surance, TIAA/CREF, and reduced tuition for 
dependents. UTSI occupies a scenic 365 acre 
iakeshore campus. 

Send a detai led resume and names of three refer¬ 
ences to: Professor Moonis Ali, Chairman, Com¬ 
puter Science Committee, The University of Ten¬ 
nessee Space Institute, Tullahoma, TN 37388. 
(phone: (615) 455-0631, ext. 283). 

UTSI is an AA/EEO employer 


THE UNIVERSITY OF TEXAS AT ARLINGTON 

The Department of Computer Science Engineer¬ 
ing (CSE) at The University of Texas at Arlington 
(UTA) invites your application for tenure-track or 
visiting faculty positions in all areas of computer 
science and computer engineering. Rank is 
open. An earned doctorate or equivalent and 
commitment to teaching and scholarly research 
is required. Openings are expected for Septem¬ 
ber 1988. Interested persons should send a 
resume to Bill D. Carroll, Professor and Chair¬ 
man, Computer Science Engineering Department, 
P.O. Box 19015, The University of Texas at Arl¬ 
ington, Arlington, TX 76019. Phone 817-2733785. 
The University of Texas at Arlington is an Equal 
Opportunity Affirmative Action Employer. 
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UNIVERSITY OF DELAWARE 
Department ol Computer and 
Information Sciences 

Are you interested in joining the computer 
science faculty of a growing, dynamic depart¬ 
ment in an attractive university town within easy 
traveling distance to New York, Philadelphia, 
Baltimore, and Washington? The University of 
Delaware, centrally located on the East Coast, is 
recruiting for possible openings for tenure-track 
and visiting faculty positions in the Department 
of Computer and Information Sciences begin¬ 
ning September 1, 1988. Strong applicants in all 
areas of computer science are encouraged to ap¬ 
ply. Special interest exists for candidates with 
research expertise in symbolic mathematical 
computation, parallel processing, artificial in¬ 
telligence, networking, graphics, programming 
languages and software engineering. 

A Ph.D. degree or its equivalent, and excellence 
in research and teaching are required. Salary and 
rank will be commensurate with the candidate’s 
qualifications and experience. 

The Computer and Information Sciences Depart¬ 
ment offers bachelor, master, and doctoral 
degrees. Resources devoted to academic use in 
the-University Computing Center include: an 
IBM 3081D, an CDC Cyber 174, a Vax 8600 and 
Pyramid 98xe both running Unix, and more than 
75 microcomputers (IBM PC-XT's, AT’s and 
Macintosh’s). 

The Department research facilities include vari¬ 
ous workstations (Symbolics Lisp machines, 
Micro-Vax II, SUN-3’s, and IBM-AT’s) and facili¬ 
ties in a joint research lab shared with the 
Department of Electrical Engineering. The latter 
includes a VAX-8500, three VAX 780’s and vari¬ 
ous other smaller machines. The equipment is 
connected to the ARPAnet, CSNet, and to 
BITNET. 

Candidates should send a curriculum vitae and 
the names of three references to Professor 
Claudio Gutierrez, Department of Computer and 
Information Sciences, University of Delaware, 
Newark, DE 19716. Positions are open until filled. 
The University of Delaware is an equal opportuni¬ 
ty, affirmative action employer. Applications 
from members of minority groups and women 
are encouraged. 


UNIVERSITY OF BRIDGEPORT 
Computer Engineering 

Tenure track positions in Computer Engineering 
available September 1988. Candidates should 
have strong commitment to computer engineer¬ 
ing education plus strong background in any of 
the following: computer hardware, digital de¬ 
sign, VLSI design, image processing, pattern 
recognitive and computer organization among 
others. Ph.D. in Computer Engineering preferred 
but degrees in related areas with extensive com¬ 
puter experience will be considered. The Univer¬ 
sity is located in prestigious Fairfield County, 
Connecticut within easy driving distance of New 
York and Boston. The primary goal of the engi¬ 
neering college is instruction, but we are pre¬ 
sently developing a larger research emphasis 
through the Connecticut Technology Institute, 
initially funded through a five million dollar 
federal grant. Facilities include VAX 785, DEC 
20/60, PC lab, VLSI design lab, Al workstations 
lab, digital signal processing lab using Tl 320 
chips connected to PC’s, Z80 microcomputer 
hardware lab, and 8086 microcomputer software 
lab. Send resume and at least three current 
references to: Dr. Stephen Grodzinsky, Depart¬ 
ment of Computer Science and Engineering, 
University of Bridgeport, Bridgeport, CT 06601. 

An Equal Opportunity Employer 


THE PENNSYLVANIA STATE UNIVERSITY 
Computer Engineering 

Applications are invited for tenure-track and 
visiting faculty positions at all levels. Can¬ 
didates from all areas of computer engineering 
(hardware and software) will be considered. The 
Computer Engineering Program at The Pennsyl¬ 
vania State University is within the Department 
of Electrical Engineering which has over 50 
faculty members, and approximately 1500 under¬ 
graduate majors, 170 graduate students. Can¬ 
didates should have a Ph.D. in Electrical/Com¬ 
puter Engineering or related areas. There are 13 
faculty members within the Computer Engineer¬ 
ing Program. Excellent instruction and research 
computing facilities are available within the 
Department, College and at the University Com¬ 
puting Center. 

Please send your letter of application, resume, or 
inquiries, together with three references to: T. 
Feng, Computer Engineering Program, Depart¬ 
ment of Electrical Engineering 129 Electrical 
Engineering East, Box ES, The Pennsylvania 
State University, University Park, PA 16802. 
Deadline for applications is June 30,1988 or until 
suitable qualified candidates are selected. “An 
Equal Opportunity/Affirmative Action Employer.” 


CONCORDIA UNIVERSITY 

The Department of Computer Science CONCOR¬ 
DIA UNIVERSITY, is seeking qualified can¬ 
didates for a tenure track position. Preference 
will be given to candidates in the area of distri¬ 
buted computing and programming languages, 
however, strong candidates in other areas of 
Computer Science are also encouraged to apply. 
Applicants should have a Ph.D. degree in Com¬ 
puter Science or related field with a good 
research record. The Department currently has 
26 full-time professors. It offers both under¬ 
graduate and graduate programs up to the Ph.D. 
level with an enrollment of over 1000 students. 
The language of instruction is English. Depart¬ 
mental facilities include VAX 11/750, SUN work¬ 
stations, VLSI design stations, PCs, and INTEL 
310s. Available university facilities include a 
VAX 8500 and a CDC Cyber dual 830, plus under¬ 
graduate teaching machines. Apply, giving re¬ 
sume and the names of at least three references 
to: Dr. T.D. Bui, Chairman, Department of Com¬ 
puter Science, CONCORDIA UNIVERSITY, 1455 
de Maisonneuve Blvd. West, Montreal (Quebec) 
CANADA, H3G 1M8. In accordance with Canadian 
immigration requirements, priority will be given 
to Canadian citizens and permanent residents. 


UNIVERSITY OF SOUTH CAROLINA 
AT SPARTANBURG (USCS) 

University of South Carolina at Spartanburg 
(USCS) tenure-track; rank and salary open. Ph.D. 
in Computer Science or a related field preferred; 
ABD or M.S. will be considered. Department 
serves 100 majors and supports 30 business data 
processing majors. USC computer system con¬ 
sists of twin IBM 3081’s and campus microcom¬ 
puters. The department is committed to excel¬ 
lence in teaching and provides a supportive 
atmosphere for research. Send letter of applica¬ 
tion, resume, official graduate and undergradu¬ 
ate transcripts, and three letters of recommenda¬ 
tion to Computer Science Search Committee, 
Office of the Dean, School of Humanities and 
Sciences, Box B, University of South Carolina at 
Spartanburg, Spartanburg, S.C. 29303. The 
search will continue until the position is filled. 
USCS is an affirmative action/equal opportunity 
employer. Currently, 40% of the faculty of the 
School of Humanities and Sciences are women 
and 6% represents minority groups. Women and 
minorities are encouraged to apply. 


CASE INSTITUTE OF TECHNOLOGY 
Case Western Reserve University 

We invite applications for tenure-track faculty 
positions at all levels. We are particularly in¬ 
terested in candidates whose research areas in¬ 
clude VLSI systems and design automation, ap¬ 
plied artificial intelligence, data bases, software 
design environments, parallel computation, and 
analysis of algorithms. Applicants will be judged 
primarily on their ability to strengthen our quest 
for excellence in research and teaching. 

CWRU is a small private university with a total 
enrollment of about 8400, of which about 5100 
are graduate and professional students. The uni¬ 
versity campus is the hub of the pleasant area 
known as University Circle, an incorporation 
with neighboring cultural centers and museums. 
University Circle is about 10 miles from down¬ 
town Cleveland. 

Case Institute of Technology, a subunit of CWRU, 
is among the top ten engineering schools in 
terms of research funding per faculty member 
and undergraduate student quality. The depart¬ 
ment of Computer Engineering and Science has 
a young faculty of 10 and growing, and a gradu¬ 
ate student body of 115 students, 48 of which are 
currently in the Ph.D. program. Department facil¬ 
ities include a DEC VAX-11/780, Data General 
MV/10000, numerous desk-top computers (Intel, 
DEC, Sun and Apollo), several color graphic 
displays (four high and ten medium resolution), 
and hard-copy equipment (color ink jet and laser 
printers, plotters, etc.). Faculty and students par¬ 
ticipating in the Center for Automation and In¬ 
telligent Systems Research have access to the 
Center’s VAX-11/782 and VAXstation 100 display 
systems. Educational computing is provided by 
the Computing Center with three DEC-2060’s the 
Case Personal Computer Lab with 48 DEC PRO 
350’s, four AT&T 3B2’s and several AT&T 6300’s, 
and the department’s MV/10000. 

Applicants should submit their resume and 
names of three references to: Professor J. 
Thomas Mortimer, Chairman; Department of 
Computer Engineering and Science; Case 
Western Reserve University, Cleveland, Ohio 
44106. 

An Equal Opportunity Affirmative Action Em- 


UNIVERSITY OF ROCHESTER 
Electrical Engineering 

We expect to fill several faculty positions in 
computer engineering or related areas. Current¬ 
ly, we have faculty groups active in VLSI design 
and testing, robotics, image/signal processing, 
computer system design automation, and net¬ 
working. Those appointed would carry out 
research in computer engineering and teach 
related material to graduate and undergraduate 
students. Applicants should have an established 
research record or, for very recent graduates, a 
commitment to establish such a record. These 
positions are expected to be filled at the Assis¬ 
tant Professor level. However, in exceptional 
cases a higher level of appointment may be forth¬ 
coming. Salary commensurate with experience. 
These are tenure track positions and candidates 
are expected to hold or to receive soon their Doc¬ 
torate in Electrical Engineering or Computer 
Science or a closely related field. We are par¬ 
ticularly interested in women and minority can¬ 
didates. The University of Rochester provides a 
receptive environment with excellent students 
and established research. Applicants should send 
a full resume, a statement of research plans, and 
copies of relevant publications to: Professor 
Sidney Shapiro, Chair, Dept, of Electrical 
Engineering, University of Rochester, Rochester, 
NY 14627. The University of Rochester is an Equal 
Opportunity Employer (M/F). 
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UNIVERSITY OF CALIFORNIA, DAVIS 
Faculty Positions In Electrical Engineering 
and Computer Science 

The Department of Electrical Engineering and 
Computer Science at UC Davis invites applica¬ 
tions for tenure track positions at all ranks. The 
primary areas of interest are image processing, 
computer engineering, and computer science. 
The department, with forty-six faculty members 
and 150 full-time graduate students, is experi¬ 
encing rapid growth. Our College is the nation's 
sixteenth largest producer of engineering 
Ph.D.’s in a University which has the nineteenth 
largest extramural research funding. Salary and 
benefits are extremely attractive. 

Davis is a pleasant, family-oriented community 
near Sacramento, within easy driving distance to 
Silicon Valley, the Lawrence Livermore National 
Laboratory, San Francisco, the Pacific Ocean, 
and the Sierra Nevada Mountains. 

We are seeking individuals with strong records 
of teaching and research with ambitious plans. 
Senior appointments require outstanding re¬ 
cords of achievement; junior appointments must 
show evidence of great promise. All faculty are 
expected to have a strong commitment to teach¬ 
ing at all degree levels, and to demonstrate the 
ability to attract significant research support. 
The positions require a Ph.D. degree or equival¬ 
ent, and are open until filled. Send a resume and 
the names of at least three references to: 
Professor S. Louis Hakimi, Chair 
Department of Electrical Engineering and 
Computer Science 
University of California 
Davis, CA 95616 

The University of California, Davis, is an equal 
opportunity/affirmative action employer. 


INDIANA UNIVERSITY-PURDUE UNIVERSITY 
At Indianapolis 

The Department of Computer and Information 
Science invites applications for tenure track 
positions in all specialties. A Ph.D. in Computer 
Science or related field is required. Duties in¬ 
clude research and six hours teaching. Rank and 
salary depend upon the candidate’s qualifica¬ 
tions. The positions are open until filled. 

The Department is embarking on a significant 
expansion of its research efforts. Successful 
candidates will play a prominent role in this ef¬ 
fort, as well as contribute to the growth of a ma¬ 
jor institution. The Department especially seeks 
individuals who will participate in its ongoing 
research in Applied Software and in Program¬ 
ming Languages. 

The Purdue School of Science, in which the 
Department resides, is a major part of Indiana 
University-Purdue University at Indianapolis. 
IUPUI, a state university with an enrollment of 
over 23,000 students, has a mission to interact 
with the dynamic industrial community centered 
around Indianapolis. Its unique relationship with 
Purdue University at West Lafayette and Indiana 
University at Bloomington affords opportunities 
for joint research. The six-hospital Medical 
Center at IUPUI is yet another source of cross- 
disciplinary research for the Department. Out¬ 
standing computing facilities include a network 
of IBM, DEC, CDC and Prime machines. 
Indianapolis itself has received national recogni¬ 
tion as one of the best U.S. cities in which to live. 
Host of the 1987 Pan American Games, it enjoys 
numerous recreational and cultural activities, in¬ 
cluding a symphony, opera, and various theater 
groups. Its moderate cost of living and progres¬ 
sive civic leadership foster this rich environment. 
Please send resumes and references to Dr. An¬ 
drew Olson, Chairman, Department of Computer 
& Information Science, Box 647, IUPUI, In¬ 
dianapolis, IN 46223. IUPUI is an Equal Oppor¬ 
tunity/Affirmative Action Employer. 


UNIVERSITY OF HOUSTON 

Applications are invited for tenure track faculty 
positions in the Department of Computer Sci¬ 
ence starting September 1988. Areas of special 
interest include but not limited to artificial in¬ 
telligence, computer architecture, operating 
systems, programming languages and software 
engineering. Rank and salary are open and com¬ 
petitive. The Department is interested in expan¬ 
ding its research program and particularly wel¬ 
come applicants for senior positions. Applicants 
should have a Ph.D. in Computer Science or a 
closely related area, and a strong commitment to 
research and teaching. Candidates for senior 
positions should also have a distinguished re¬ 
search record. The Department offers Ph.D., 
M.S., and B.S. in Computer Science. Departmen¬ 
tal research facilities include a network of SUN 
Workstations, VAX 11/780 and VAX 11/730’s, a 
network of AT + T 3B20 and 3B2’s and access to 
other computing facilities in the University Com¬ 
puter Center as well as supercomputers via re¬ 
mote access terminals. Send resume and names 
of professional references to Dr. Willis King, 
Chairman, Department of Computer Science, 
University of Houston, Houston, Texas 77004. An 
Equal Opportunity/Affirmative Action Employer. 


CLEVELAND STATE UNIVERSITY 

TENURE-TRACK FACULTY: The Department of 
Computer and Information Science at Cleveland 
State University has a tenure-track position at 
any level to begin Fall, 1988. Responsibilities in¬ 
clude teaching (two courses/quarter) & research 
participation. Salary is very competitive. Quali¬ 
fications: Ph.D. in Computer Science, MIS, Com¬ 
puter Engineering, or a closely related field. For 
instructor positions, Ph.D. candidates with some 
or substantial progress on a dissertation will be 
considered. Close relationships to business, 
engineering, science, and other departments 
provide an environment conducive to research 
and consulting. In addition to university com¬ 
puting facilities, the department provides its 
own laboratories using VAX and other com¬ 
puters running UNIX and VMS and state-of-the- 
art software for faculty and students. Faculty of¬ 
fices are equipped with personal computers. In¬ 
quiries and vita should be sent to: Dr. Thomas S. 
Heines, Chairperson, Computer & Information 
Science Dept., Cleveland State University, E. 
24th & Euclid Ave., Cleveland, OH 44115. EOE, 
m/f/h. 


UNIVERSITY OF WISCONSIN-MILWAUKEE 
Department of Electrical Engineering and 
Computer Science 

The Department expects to have Computer 
Science faculty openings. Candidates should 
have a Ph.D. in Computer Science or a closely 
related discipline. A strong commitment to 
research and teaching is expected. Senior can¬ 
didates should have an excellent research 
record. Areas of special interest are: artificial in¬ 
telligence, networks, compilers, software engi¬ 
neering, and theory. 

The Department's current research strengths in¬ 
clude theory, architecture, parallel computation, 
data-security and databases. The University 
campus is located near the shores of Lake 
Michigan and is close to pleasant and beautiful 
residential areas. Interested persons should 
send a resume with three references to: 
Professor K. Vairavan 
Chairman—Computer Science 
Dept, of Elec. Eng. and Comp. Sci. 

UW—Milwaukee 
P.O. Box 784 
Milwaukee, Wl 53201 


Tulane is a major private university, selective in 
enrollment and comprehensive in scope, with 
about 10,000 undergraduate and graduate stu¬ 
dents. The campus is located in a residential 
area of uptown New Orleans, one of America's 
most distinctive cities. Faculty benefits include 
dependent tuition, mortgage assistance, reloca¬ 
tion expenses, 12% TIAA and typical insurance 
benefits. 

Departmental computer systems include a VAX 
11/780 running under VMS, a Pyramid 90x run¬ 
ning under Unix, a Sun network, and several 
microcomputer clusters. The Pyramid is dedi¬ 
cated to departmental research; other systems 
are divided between research and teaching. In 
addition to departmental resources, the Univer¬ 
sity maintains an IBM 3081/KX. 

The department invites applications for faculty 
positions at all levels for the 1988-89 academic 
year. Candidates should have a Ph.D. in Compu¬ 
ter Science or a related area. Research excel¬ 
lence or demonstrated research potential and a 
commitment to quality teaching are required. 
Applicants for instructorships must possess a 
masters in Computer Science or be ABD. The 
availability and level of faculty positions are 
dependent on funding levels. 

Applications should be directed to 
Dr. Johnette Hassell, Head 
Department of Computer Science 
School of Engineering 
301 Stanley Thomas Hall 
New Orleans, LA 70118 

Applications must be received by March 15,1988 
for fall appointment. Tulane University is an Affir¬ 
mative Action Equal Opportunity Employer. 


THE OHIO STATE UNIVERSITY 
Department of Computer and 
Information Science 

Applications are invited for faculty positions at 
all levels. A Ph.D. in computer science or a close¬ 
ly related field is required. Of special interest are 
candidates in the areas of artificial intelligence, 
computer graphics, databases, numerical analy¬ 
sis, programming languages, operating systems, 
parallel and distributed computing, software 
engineering, and VLSI design. Special research 
support packages are available for highly quali¬ 
fied candidates. 

Computing facilities within the Department in¬ 
clude a DEC-2060, three Pyramids, 20 Sun-3 
workstations, 10 IBM RTs, 15 Xerox LISP 
machines, an Intel iPSC/5 Hypercube, an Encore 
Multimax, a BBN Butterfly, numerous other 
systems for graphics, robotics, etc., and over 300 
Macintoshes. Macs are used in introductory 
computing courses. An additional 200 Sun-3 
workstations and 6 Hewlett Packard color 
graphics workstations will be installed this year 
for other instructional use. The OSU Computing 
Center facilities include a Cray XMP, IBM 
3081-D, and several IBM 4341s. All systems are 
attached to a campus-wide fiber optic network 
(Pronet 80) using TCP/IP protocols. Access is 
available to the national networks (ARPANET, 
CSNET, BITNET, USENET). 

To apply, please send application and resume to 
Prof. Ming T. (Mike) Liu, Chairman of Faculty 
Search Committee, Department of Computer 
and Information Science, The Ohio State Univer¬ 
sity, 2036 Neil Avenue, Columbus, Ohio 43210- 
1277 Ohio-State.) In order to expedite considera¬ 
tion, please ask three references to send their 
confidential letters directly to Prof. Liu. The Ohio 
State University is an equal opportunity/affir¬ 
mative action employer. 
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OREGON STATE UNIVERSITY 
Department of Computer Science 

The Department of Computer Science invites 
qualified applicants for Assistant, Associate and 
Full Professors, tenure-track, nine-month to 
begin September 1988. Specialization in pro¬ 
gramming languages and systems, information- 
based systems, theoretical computer science, 
computer architecture, artificial intelligence or 
computer graphics is desirable. Applicants 
should have completed or expect to complete all 
requirements for a Ph.D. in computer science or 
a closely related field and should have demon¬ 
strated research and teaching potential. Can¬ 
didates for senior positions should have an 
established research reputation. Review of ap¬ 
plications will begin November 1,1987, and will 
continue until the positions are filled. Please 
send resume, including the names of three refer¬ 
ences, to: Walter G. Rudd, Chairman, Depart¬ 
ment of Computer Science, Oregon State Univer¬ 
sity, Corvallis, OR 97331. 

Oregon State University is an equal opportunity 
affirmative action employer and complies with 
Section 504 of the Rehabilitation Act of 1973. 


UNIVERSITY OF WASHINGTON 

The Department of Computer Science may have 
openings for tenure-track faculty appointments 
starting in the 1988-89 academic year. We are 
particularly interested in applicants with re¬ 
search strengths in artificial intelligence, data¬ 
bases, and programming languages and compil¬ 
ers. However, applications from outstanding in¬ 
dividuals in other areas might also be considered. 
A moderate teaching load allows time for quality 
research and close involvement with students. 
We expect applicants to have a strong commit¬ 
ment to both research and teaching, and an out¬ 
standing record of research for their level. Any 
appointment should bring significant new re¬ 
search strength to the department. 

The department may also have several visiting 
positions that would require both teaching and 
research. It may be possible to hold these for 
portions of the 1988-89 academic year. 
Interested applicants should send a letter of ap¬ 
plication, a resume, and the names of four refer¬ 
ences to Paul Young, Chairman, Department of 
Computer Science FR-35, University of Washing¬ 
ton, Seattle, Washington 98195. 

The University of Washington is an Affirmative 
Action/Equal Opportunity Employer. The Ph.D. is 
required for these positions. 


UNIVERSITY OF TENNESSEE SPACE INSTITUTE 
Graduate Research Assistants 
in Computer Science 

Applications are invited for graduate research 
assistants in computer science, particularly in 
artificial intelligence. UTSI awards M.S. and 
Ph.D. degrees in computer science with empha¬ 
sis on applied artificial intelligence, expert 
systems and robotics. 

UTSI offers total financial assistance packages 
including tuition, fees, and monthly stipends 
which average $11,600 to $12,600 for an aca¬ 
demic 9 month appointment depending upon the 
degree program. In addition, summer appoint¬ 
ments may be available. To receive an applica¬ 
tion or for further information, please contact: 
Dr. Charles Lea, Director, Admissions and Stu¬ 
dent Services, The University of Tennessee 
Space Institute, Tullahoma, TN 37388 (phone: 
(615) 455-0631, ext. 296). 

UTSI is an AA/EEO employer 


AUSTRALIAN NATIONAL UNIVERSITY 

Applications are invited for appointment to the 
position of POSTDOCTORAL FELLOW/RE¬ 
SEARCH FELLOW IN CONCURRENT COMPUTA¬ 
TION, CENTRE FOR INFORMATION SCIENCE 
RESEARCH. A research position is available for 
an applicant with a PhD in computer science or 
an appropriate related discipline and with strong 
research interests in some aspect of concurrent 
computation. The successful applicant will be 
responsible for a concurrent computation labor¬ 
atory, which includes a Transputer Development 
System with about twenty processors, under the 
direction of Professor R.P. Brent of the Com¬ 
puter Sciences Laboratory, Research School of 
Physical Sciences. The Computer Sciences Lab¬ 
oratory has an active research group working in 
aspects of parallel computation, including 
parallel algorithms, systolic arrays, and applica¬ 
tions of transputer systems to image process¬ 
ing. The post is funded by the Centre for Informa¬ 
tion Science Research, and it is intended that 
the successful applicant will foster use of the 
concurrent computation laboratory by all in¬ 
terested members of the Centre, including the 
Department of Computer Science (Faculty of 
Science) and the Automated Reasoning Project 
(Research School of Social Sciences). Further in¬ 
formation from Professor R.P. Brent (062)493329 
Closing date: 15 March 1988 Ref: IS 3.12.1 
SALARY: Postdoctoral Fellow Grade 1 (fixed 
point); A$24,535-A$28,029 p.a.; Research Fellow; 
A$28,381 -A$37,122 p.a.; APPOINTMENT: 
Research Fellow up to three years, possibility of 
extension to five years; Postdoctoral Fellow nor¬ 
mally two years, possibility of extension to three 
years. APPLICATIONS should be submitted in 
duplicate to the Registrar, The Australian Na¬ 
tional University, GPO Box 4, Canberra ACT 
2601, quoting reference number and including 
curriculum vitae, list of publications and names 
of at least three referees. The University reserves 
the right not to make an appointment or to ap¬ 
point by invitation at any time. Further informa¬ 
tion is available from the Registrar. 

THE UNIVERSITY IS AN EQUAL 
OPPORTUNITY EMPLOYER 


UNIVERSITY OF ALBERTA 
Department of Computing Science 

Applications are invited for two tenure-track 
positions at the Assistant/Associate Professor 
level. Responsibilities include research as well 
as teaching at the graduate and undergraduate 
levels. Strong candidates from all research areas 
will be considered, but areas of special interests 
include database systems, VLSI/computer ar¬ 
chitecture, operating systems, numerical 
analysis and computer graphics. 

The Department consists of 36 academic and 28 
support staff. Current hardware support includes 
an Amdahl 5870, a network of four VAX 11/780’s 
and about thirty Sun Workstation^, and well- 
equipped microcomputer and workstation labor¬ 
atories for graphics, VLSI, and Al research. 
Access to a Cyber 205 is available. 

Salary range $32,756 to $57,236 and is commen¬ 
surate with qualifications and experience. Send 
curriculum vitae and the names of three refer¬ 
ences, and up to three reprints or copies of im¬ 
portant publications. New Ph.D.'s should also in¬ 
clude a copy of their transcript. Apply to: 

Dr. Lee J. White, Chairman 
Department of Computing Science 
University of Alberta 
Edmonton, Alberta. Canada 
T6G 2H1 

Applications will be accepted until June 30, 
1988. 

The University of Alberta is committed to the 
principle of equity in employment 


AUBURN UNIVERSITY 
DEPARTMENT OF COMPUTER SCIENCE 
AND ENGINEERING 

Applications are invited for tenure-track faculty 
positions at the Associate Professor level. Appli¬ 
cations at the Assistant Professor level will also 
be considered. A Ph.D. in Computer Science, 
Computer Engineering, Electrical Engineering or 
a closely related discipline is required. Preferred 
areas of interest include but are not limited to 
Computer Architecture, Data Base Systems, and 
Operating Systems. Positions are open for the 
87/88 academic year. Salary and faculty rank are 
competitive depending upon experience and 
qualifications. Responsibilities include teaching 
at the graduate and undergraduate levels and 
building the on-going research program. The 
department offers Bachelor’s degrees in Com¬ 
puter Science and Computer Engineering as well 
as the M.S. and Ph.D. An outstanding research 
program has been established in the above 
disciplines. Applicants should submit a detailed 
resume and three references to Chair of the 
Search Committee, Department of Computer 
Science and Engineering, Auburn University, AL 
36849-5347. Minorities and women are encour¬ 
aged to apply. Auburn University is an Equal 
Opportunity/Affirmative Action Employer. 


NEW JERSEY INSTITUTE OF TECHNOLOGY 
Computer and Information Science 

Department seeks assistant, associate and full 
professors for spring/fall 1988. Ph.D. in computer 
science or closely related field required. Senior 
level applicants must have proven research and 
funding record. Positions available in, but not 
limited to: distributed computing including com¬ 
puter architecture, data communications net¬ 
working, realtime computing and fault tolerance; 
software development including artificial intelli¬ 
gence, expert systems, computer graphics; office 
automation, data management systems, cog¬ 
nitive science, and computational linguistics. 
Department offers B.S., B.A., M.S., and Ph.D., in 
computer science, and Ph.D. in management 
jointly with Rutgers-Newark. Computing facili¬ 
ties include VAX 8800, VAX 8530, IBM 4361, SUN 
workstations, Symbolics machines, Tl Explorers 
and graphics systems. 

NJIT is the comprehensive technological univer¬ 
sity of New Jersey with 7700 students enrolled in 
Newark College of Engineering, the School of Ar¬ 
chitecture, and College of Sciences and Liberal 
Arts. 

Send resume and names of at least three refer¬ 
ences to: 

Personnel Box CIS 

New Jersey Institute of Technology 

Newark, NJ 07102 EO/AA employer 
NJIT does not discriminate on the basis of sex, 
race, color, handicap, national or ethnic origin, or 
age in employment. 


GETTYSBURG COLLEGE 
Gettysburg, PA 17325 

Position for Fall 1988. Tenure track Assistant 
Professor. Ph.D. in Computer Science preferred. 
Minimum Requirement Ph.D. in related field with 
Master’s Degree in Computer Science. 

Very selective coed liberal arts college. 1800 
students. Historic location in rural south-central 
PA with proximity to Washington and Baltimore. 
Extensive computing facilities, CS major. Oppor¬ 
tunities to develop an evolving CS curriculum. To 
guarantee consideration applications should be 
received by Feb. 15,1988. Send resume and 3 let¬ 
ters of reference to: Professor L. Carl Leinbach, 
Chair, Computer Science. Equal Opportunity/ 
Affirmative Action Employer. Women and minor¬ 
ity candidates encouraged. 
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UNIVERSITY OF COLORADO AT DENVER 
Computer Science and Engineering 

The Department of Electrical Engineering and 
Computer Science invites applications for an¬ 
ticipated tenure-track faculty positions in Com¬ 
puter Science and Engineering. Applicants must 
have an earned doctorate in computer science or 
a related field, and a demonstrated record of ac¬ 
complishment in computer science and engi¬ 
neering. The computer science student body is 
diverse and mature, with interests in applied 
computer science and engineering. Individuals 
with industrial as well as academic backgrounds 
will find the department a rewarding environ¬ 
ment for teaching and research. 

Present research interests in the department in¬ 
clude artificial intelligence, robotics, computer 
architecture, parallel computing, and software 
engineering. The department supports a VAX, 
Sun workstations, and numerous personal com¬ 
puters for faculty use. In addition, the depart¬ 
ment has access to a variety of mainframes, in¬ 
cluding a Cyber 205. The department encour¬ 
ages the development of sponsored research 
programs and scholarly publication. The depart¬ 
ment and the College of Engineering and Ap¬ 
plied Science have recently moved into a new 
building in downtown Denver. 

Applicants should submit a current vita and have 
at least four letters of reference sent to John 
Clark, Chairman, Department of Electrical Engi¬ 
neering and Computer Science, University of 
Colorado at Denver, Campus Box 110,1200 Lari¬ 
mer Street, Denver, CO 80204. Non-citizens 
should identify the nature and status of their 
visas. Applications will be accepted until the 
positions are filled. The University of Colorado at 
Denver is an Equal Opportunity/Affirmative Ac¬ 
tion Employer. 


SANTA CLARA UNIVERSITY 
Assistant Professor of Electrical Engineering 
Associate/Full Professor of 
Computer Engineering 

Santa Clara University’s EECS department in¬ 
vites applications for two tenure-track positions: 
The first is an Assistant Professor of Electrical 
Engineering in the areas of Digital Signal Pro¬ 
cessing and Control or Electronic Circuits and 
Systems. The second is an Associate/Full Pro¬ 
fessor of Computer Engineering in the areas of 
Software Engineering, Operating Systems, Al, or 
Digital Systems. 

SCU is located 45 miles south of San Francisco, 
in the center of Silicon Valley. The department 
has 19 tenure track faculty and 50 adjunct facul¬ 
ty, and offers BS, MS, and Ph.D. degrees in both 
Electrical and Computer Engineering. Engineer¬ 
ing computers include a VAX-11/750 and more 
than 60 engineering workstations; University 
academic resources include a VAX-8650, more 
than 800 IBM PCs, and a campus-wide local-area 
network. In addition, the Department operates an 
Institute for Information Storage Technology 
and modern laboratories in digital systems, 
microelectronics, and microwaves. 

Applicants must have a Ph.D., an outstanding 
research record, demonstrated teaching ability, 
and an interest in furthering cooperation with 
surrounding industry. 

Candidates should submit a resume and the 
names of at least three references to: 

Dr. Daniel Lewis, Chairman 
Faculty Search Committee 
EECS Department 
Santa Clara University 
Santa Clara, California 95053 
Santa Clara University is an Affirmative Action/ 
Equal Opportunity Employer. 


PACIFIC LUTHERAN UNIVERSITY 

The computer engineering program at Pacific 
Lutheran University invites applications for a 
tenure track position beginning September 1, 
1988. Applications should have an MS or Ph.D. in 
computer engineering, computer science, or 
electrical engineering and a strong interest in 
undergraduate teaching. Located in the Puget 
Sound region, the environment offers a mild 
climate and a wide variety of outdoor recrea¬ 
tional opportunities. Send resume and 3 refer¬ 
ences by March 15,1988 to Dr. Richard Spillman, 
Dept, of Math/CS, Pacific Lutheran University, 
Tacoma, WA 98447. PLU is an equal opportunity/ 
affirmative action employer. 

FLORIDA INTERNATIONAL UNIVERSITY 

The State University of Florida at Miami 

Director—School of Computer Science 

Florida International University invites applica¬ 
tions and nominations for the position of Direc¬ 
tor of School of Computer Science. We are seek¬ 
ing an individual with excellent leadership skills, 
a distinguished record of research, administra¬ 
tive and teaching experience suitable for ap¬ 
pointment at the rank of Professor. An earned 
Doctorate in Computer Science or related field is 
required. Salary will be commensurate with 
qualifications. 

The Computer Science program was initiated in 
1972 and elevated to the status of a School 
within the College of Arts & Sciences in the Fall 
of 1987. Currently there are 20 full-time faculty 
members performing research in many areas of 
contemporary Computer Science including dis¬ 
tributed processing, database management, 
software engineering, discrete event simulation, 
computer architecture, analysis of algorithms, 
logic of computer programs, computer graphics, 
Al and expert systems. The student population 
in the school includes approximately 600 
undergraduates, 30 Master’s students and 10 
doctoral students. 

The School of Computer Science is expected to 
play a leadership role in the University’s drive to 
move into the first rank of research universities 
while maintaining the quality of its excellent 
undergraduate program. It enjoys strong support 
from the University administration and will move 
into a new building in 1989. 

University computing is mainly done on a VAX 
8800 system. The resources of the school in¬ 
clude a VAX 750, a couple of microvaxes, 4 
Transputer workstations, Symbolics 3610, a 
Silicon Graphics IRIS 2400 Graphics system and 
numerous personal computers, all connected via 
ethernet. A $500,000 grant from the State has 
been instrumental in formulation of plans to 
modify the computer laboratory in the school. 
Current promised support calls for the expen¬ 
diture of $200,000 towards the purchase of 11 
Transputers—some with disks and one with 
graphics card, about a dozen Sun workstations 
and a Sun-4 file server. Substantial support for 
additional equipment has been committed by 
the university. 

FIU is the largest public university in South 
Florida. It has more than 16,500 students and 600 
full-time faculty members. It offers 167 aca¬ 
demic programs and courses at the Bachelor’s, 
Master’s and doctoral degree levels. 
Applications with names of 5 referees and 
Nominations should be sent to: 

Prof. Jai Navlakha 

Chairperson—Search and Screen Committee for 

DCS 

School of Computer Science 
University Park Campus 
Miami, Florida 33199. 

(305) 554-2026. 

BITNET: NAVLAKHA@SERVAX 
FIU is an Equal Opportunity/Equal Access/Affir¬ 
mative Action Employer. 


THE OHIO SUPERCOMPUTER CENTER AND 
THE OHIO STATE UNIVERSITY 

The Ohio Supercomputer Center has immediate 
openings for three user consultants and two 
systems and applications programmers. The 
center is a new organization providing access to 
supercomputing for universities, colleges and 
industries in the state of Ohio. Our equipment in¬ 
cludes a CRAY X-MP/24, with SSD, running the 
UNICOS operating system. 

User Consultants: The openings for user con¬ 
sultants include one senior and two staff posi¬ 
tions. Applicants for the senior position should 
have extensive experience in development or 
support of scientific software using FORTRAN 
or C on supercomputers (preferably CRAY) and 
experience in technical teaching. UNIX ex¬ 
perience is preferred. Applicants for the staff 
positions should also have experience in sup¬ 
port of scientific software. Teaching experience 
or experience with UNIX and supercomputers is 
preferred. 

Programmers: The openings for programmers in¬ 
clude a group leader position and a position in 
the systems and applications programming 
group. The group leader should have extensive 
systems experience on supercomputers as well 
as supervisory experience. For systems pro¬ 
grammers extensive experience with either 
UNIX time sharing systems or VAX VMS 
operating systems is required. For applications 
programmers experience in writing and main¬ 
taining scientific/engineering software pack¬ 
ages is essential as is a working knowledge of 
numerical methods. 

Salaries will be commensurate with experience. 
To apply, send resume and have two letters of 
reference sent to: Ohio Supercomputer Center, 
1224 Kinnear Road, Columbus, OH 43212. The 
Ohio Supercomputer Center/The Ohio State Uni¬ 
versity is an Equal Opportunity, Affirmative Ac¬ 
tion Employer. 


UNIVERSITY OF NORTH CAROLINA 
AT CHARLOTTE 

Department of Computer Science 

Several tenure-track positions in all areas at 
Assistant, Associate, or Full Professor level in 
Computer Science/Computer Engineering. Salary 
and rank dependent on qualifications and ex' 
perience. Salary is competitive. Ph.D. in CS/CE 
preferred. Ph.D. in a related area to CS/CE con¬ 
sidered. Applications accepted until the posi¬ 
tions are filled. The Department of Computer 
Science is housed in the College of Engineering 
and offers both undergraduate and graduate 
degrees in computer science. Active research 
areas in the department include artificial in¬ 
telligence, computer architecture, computer vi- 
sion/robotics, database systems, data communi¬ 
cation, theoretical CS, VLSI design. On-campus 
Ph.D. level research and study are available 
through cooperation with other participating in¬ 
stitutions of the Microelectronics Center of N.C. 
(MCNC). A wide variety of excellent computing 
facilities including IBM, VAX, Burroughs, Harris, 
Xerox, Sun, and others are available to support 
educational and research activities. Also, as a 
participant in MCNC, UNCC has access to state- 
of-the-art computing, VLSI design, and fabrica¬ 
tion facilities. Charlotte is the largest city in the 
Carolinas with excellent housing, good schools 
and mild climate. 

Vita, transcript and four letters of reference 
should be sent to Chairperson, Faculty Search 
Committee, Department of Computer Science, 
The University of North Carolina at Charlotte, 
Charlotte, NC 28223. 

UNCC IS AN EOE/AA EMPLOYER 
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NAVAL POSTGRADUATE SCHOOL, 
Monterey, CA 

Position Announcement in Computer Science 

The Department of Computer Science has im¬ 
mediate openings for faculty positions at all 
levels. Our primary interests are in the areas of 
operating systems, programming languages, and 
algorithms. Our secondary interests are in the 
areas of processing of visual data, real-time 
systems, and software engineering. An applicant 
should have a Ph.D. in Computer Science or a 
related field and have a strong interest in both 
graduate teaching and research. Senior appli¬ 
cants must have distinguished research records. 
Appointments can begin at any time during the 

The Department offers MS and Ph.D. degrees in 
Computer Science supported by well-equipped 
instructional/research facilities and full-time 
technical staff. The faculty normally teach for 
two quarters and conduct full-time research dur¬ 
ing the other two quarters. 

Please send a detailed resume and three letters 
of reference to: Search Committee, Computer 
Science Department (Code 52), Naval Post¬ 
graduate School, Monterey, CA 93943, tel. #(408) 
646-2449. NPS IS AN EQUAL OPPORTUNITY/AF¬ 
FIRMATIVE ACTION EMPLOYER. 


STATE UNIVERSTIY OF NEW YORK 
AT BINGHAMTON 
Professor of Computer Science 
and Department Chairman 
Department of Computer Science 
Watson School of Engineering 

The Thomas J. Watson School of Engineering, 
Applied Science and Technology of the State 
University of New York at Binghamton, seeks a 
senior computer scientist to serve as Professor 
of Computer Science and Chairman of the 
Department of Computer Science. The Depart¬ 
ment has 15 full-time faculty members and 
awards BS, MS and Ph.D. degrees with teaching 
and research activities in mainstream areas of 
computer science. 

The Watson School houses the engineering, ap¬ 
plied science, and technology programs of the 
University Center at Binghamton. Currently serv¬ 
ing about 1300 full and part-time students with 
45 faculty, the school is expected to double in 
size by 1990. Because of the heavy concentra¬ 
tion of high technology industry in the Bingham¬ 
ton area (IBM, GE, Singer-Link, Universal In¬ 
struments, etc.), programs of the Watson School 
are in high demand. 

Candidates for this position must demonstrate a 
broad base of understanding and experience in 
the discipline and its directions and exhibit a 
commitment to a balanced program of excel¬ 
lence in teaching and research, in addition to 
meeting requirements for appointment as a 
tenured full professor in the Department of Com¬ 
puter Science. 

Binghamton is 200 miles north west of New York 
City and is near the well-known Finger Lakes 
recreation area with opportunities in recreation 
in skiing, boating and hiking. The Binghamton 
airport has frequent flights to major cities in the 
East. 

Nominations and applications are solicited. Ap¬ 
plicants should send a curriculum vitae and the 
names of at least three references to: Professor 
Joseph V. Cornacchio, Chairman, Screening 
Committee, Department of Computer Science, 
Watson School of Engineering, SUNY- 
Binghamton, Binghamton, New York 13901. 

An equal opportunity/affirmative action 
employer. 


CHRISTOPHER NEWPORT COLLEGE 
COMPUTER SCIENCE POSITION FOR 
1988-1989 

Christopher Newport College invites applica¬ 
tions for a full-time faculty position in computer 
science. The appointee will be expected to teach 
both introductory and upper-level undergraduate 
computer science courses. 

An appropriate master's degree is required for 
consideration; a doctorate is preferred. Appoint¬ 
ments will be effective August 22, 1988. A 
tenure-track appointment is possible. 
Christopher Newport College is an urban, four- 
year, undergraduate, state-supported college 
located in the City of Newport News, Virginia. 
The College offers 49 different majors and con¬ 
centrations under eight baccalaureate degree 
programs. It enrolls 4400 students, has a full¬ 
time faculty of 110 (70% of whom hold earned 
doctorates or other appropriate terminal 
degrees), and a part-time and adjunct faculty of 
nearly 100. Within the context of liberal learning, 
the College is committed to meeting the needs 
of its constituencies through excellence in in¬ 
struction and through public service and 
research. 

Because the College serves an area, the demo¬ 
graphics of which reflect a population with a 
much higher percentage of minority individuals 
than the national average, the College seeks 
fauclty members with extensive experience in 
teaching, advising, and counseling minority 
students. 

Interested parties are requested to send a letter 
of application, vita, graduate transcript, and four 
letters of recommendation to: 

Dr. Dennis R. Ridley 

Assistant to the Vice President for Academic 
Affairs 

Christopher Newport College 

50 Shoe Lane 

Newport News, VA 23606 
At least two of the four letters of reference 
should be from individuals with direct know¬ 
ledge of the applicant’s experience in assisting 
minority students. Applicants will receive a com¬ 
plete position description and further details 
from the search committee. Screening of ap¬ 
plications will begin on February 1, 1988. 
Christopher Newport College employs only 
United States citizens and aliens lawfully 
authorized to work in the United States. Applica¬ 
tions from women and minorities are encouraged. 
EEO/AA 


RUTGERS UNIVERSITY 
COMPUTER ENGINEERING 

Rutgers University has openings for tenure-track 
faculty in its recently formed Computer Engi¬ 
neering Program. Applicants with speciali¬ 
zations in software engineering, VLSI design and 
testing, computer graphics, digital signal pro¬ 
cessing, computer vision, computer communi¬ 
cations, parallel processing, and computer ar¬ 
chitecture are of particular interest. Excellent 
computer and research laboratory facilities are 
available. Teaching loads are modest and reflect 
the university's objective of building a program 
with excellence in teaching and research. Ap¬ 
plicants are expected to have a strong commit¬ 
ment to both research and teaching. Interested 
individuals should send a resume and the names 
of four references to 
Professor Herbert Freeman 
Computer Engineering Program 
Rutgers University 
P.O. Box 909 
Piscataway, NJ 08854. 

Rutgers is an equal-opportunity, affirmative- 
action employer. 


UNIVERSITY OF MAINE 
Computer Science Department 

Tenure track positions are available for the Fall 
Semester 1988 at the level of Assistant Pro¬ 
fessor. Higher levels will be considered for ex¬ 
ceptional applicant. Ph.D. in Computer Science 
or related discipline required. Salary and bene¬ 
fits are very competitive. Candidates in all areas 
of Computer Science will be considered. The 
department has special interest in languages, 
graphics, operating systems, software engineer¬ 
ing, networking, data base systems, theoretical 
computer science and computer applications. 
Responsibilities include teaching two courses 
each semester and independent or collaborative 
research. The department is young, has ten 
members, a strong undergraduate program and a 
new master's program. Facilities include an IBM 
3090 processor with a vector attachment operat¬ 
ing under VM/370, a DEC VAX 11/780 and DG 
MV/1000 are also available. MicroVAX and SUN 
workstations, a PDP-11 and numerous personal 
computers are owned by the department. In¬ 
dividuals with industrial experience are en¬ 
couraged to apply. The University is one and one- 
half hours from the beautiful Bar Harbor region 
and Acadia National Park, and the same distance 
to skiing and wilderness hiking areas. Send 
resume and three letters of reference to: Prof. 
George Markowsky, Computer Science Depart¬ 
ment, University of Maine, Orono, ME 04469. 
Consideration of candidates will begin im¬ 
mediately and will continue until the positions 
are filled. Pending final administrative approval. 
The University of Maine is an Equal Opportunity/ 
Affirmative Action Employer. 


RENSSELAER POLYTECHNIC INSTITUTE 
Faculty Positions 

Department of Electrical, Computer, 
and Systems Engineering 

Applications are invited for tenure-track faculty 
positions at all levels. Areas of interest include 
but are not limited to: computer engineering, ar¬ 
chitecture and parallel processing, hardware 
design, and performance evaluation, computer 
networks, VLSI design, optical computing and 
communications, knowledge-based systems 
and artificial intelligence. The ECSE Department 
is the largest academic unit at RPI and has a rich 
tradition of research and education. The depart¬ 
ment is seeking to add faculty who bring an in¬ 
novative approach to research and teaching. Ac¬ 
tive programs in computer engineering, solid- 
state electronics and integrated circuit design, 
control systems, robotics and automation, infor¬ 
mation and decision systems, communications 
and signal processing, electronics and circuits, 
and fusion plasma systems contribute to a dy¬ 
namic research environment. In addition to the 
extensive research facilities of the department, 
there are opportunities to initiate or participate 
in interdisciplinary research programs in one of 
the major research centers of the School of Engi¬ 
neering, including the Center for Integrated Elec¬ 
tronics, Center for Interactive Computer Graphics, 
and Center for Manufacturing Productivity and 
Technology Transfer. New faculty are eligible for 
special arrangements including summer support, 
equipment, graduate student support, and re¬ 
duced teaching load in order to encourage 
growth of their research programs. Applications 
or requests for more information should be 
directed to: 

Dr. Arthur C. Sanderson 
Chairman, Department of Electrical, 
Computer, and Systems Engineering 
Rensselaer Polytechnic Institute 
Troy, NY 12180-3590 

RPI is an affirmative action/equal opportunity 
employer. 
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BOOK REVIEWS 


Editor: Wiley McKinzie, School of Computer Science and Technology, Rochester Institute of Technology, Rochester, NY 14623; Compmail, w.mckinzie; CSnet, wrm@rit 

Operating Systems: Design and Implementation 


Andrew S. Tanenbaum (Prentice 

Hall, Inc., Englewood Cliffs, 

N.J., 1987, 719 pp., $39.33) 

I have on my shelves at least 12 
introductory operating systems texts, all 
published within the past five years. 
Although they range from excellent and 
comprehensive to barely satisfactory, 
most are, in the words of Andrew 
Tanenbaum, “strong on theory and 
weak on practice.” This comment from 
the preface to his new book on operat¬ 
ing systems signals his intention to 
redress this imbalance, that is, “to pro¬ 
vide a better balance between the two.” 

A reviewer of this book certainly has 
a responsibility to evaluate whether 
Tanenbaum has achieved his goal. 
However, it may also be appropriate to 
ask whether the imbalance of which he 
speaks is really as bad as he implies. At 
my institution, the introductory operat¬ 
ing systems course (at both the under¬ 
graduate and the graduate level) covers 
the fundamental concepts of operating 
system design, building on an elemen¬ 
tary discussion of the theory of concur¬ 
rent processes. A second course 
provides practical experience in the 
implementation of such a system. We 
are pretty satisfied with this approach, 
although I do find it useful to be able to 
illustrate certain issues with simple 
examples, often drawn from implemen¬ 
tations done in the second course. 

Having described a typical approach 
to the teaching of the fundamentals, I 
want to return to Tanenbaum’s book 
and evaluate whether it offers an attrac¬ 
tive alternative. He begins with the 
obligatory definition of the term “oper¬ 
ating system” and a brief history of 
operating system design. He then 
divides the discussion into four major 
topics: processes (including CPU 
scheduling), input/output, memory 
management, and file systems. At this 
level, the organization is similar to that 
of many other texts in the field. Tanen¬ 
baum’s book is unique in the inclusion 
of the source code of a full-service 
timesharing system. This system, Minix, 
with supporting documentation, occupies 
half the book. Minix is not a toy sys¬ 
tem. It is compatible with AT&T Unix, 
Version 7, at the command (shell) and 
system levels. He rewrote Version 7 
from scratch to circumvent licensing 
restrictions and make it available for 


teaching and study. He states that he 
chose this version of Unix as his model 
“because of its simplicity and ele¬ 
gance.” He calls Version 7 “not only an 
improvement over all its predecessors, 
but also over all its successors.” His 
implementation is thoroughly up-to- 
date. Unlike Unix, it is based on the 
client-server model and uses a minimal 
kernel to perform process management 
and support message passing. 

Tanenbaum devoted a chapter to 
each of the four main topics. The dis¬ 
cussion of certain issues, for example, 
concurrent processes, scheduling 
algorithms, and memory management, 
is briefer than that found in many other 
texts. The coverage of input/output and 
file systems is correspondingly longer 
and in more depth. This choice of 
emphasis was deliberate: 

Most books and courses devote an enor¬ 
mous amount of time to scheduling 
algorithms, for example, which in practice 
are usually less than a page of code, while 
completely ignoring I/O which is often 30 
percent of the system, or more. 

Each chapter falls naturally into two 
parts. The first focuses on general, the¬ 
oretical principles, and the second dis¬ 
cusses the relevant components of the 
Minix system. The last chapter is an 
annotated reading list and bibliography. 
The remainder of the book is a set of 
appendices that contain the documenta¬ 
tion and code for Minix. Except for the 
last, each chapter ends with an adequate 
set of challenging exercises—some the¬ 
ory, some practice. 

Does Tanenbaum succeed in the goals 
he set himself? This is an interesting 
and challenging book, but ultimately I 
would have to say that it achieves only 
qualified success. The trouble is that the 
theory has to compete not only with the 
code but also with the description of the 
implementation. The code is volumi¬ 
nous and its structure is complex, 
requiring considerable explanation. The 
result is that, even in a book of more 
than 700 pages, too many important 
topics chase too little space. 

For the professional programmer 
who wants some insight into the issues 
involved in writing a real system, as well 
as an introduction to the theory, this 
book is a worthwhile investment. As a 
basic text in operating systems, how¬ 
ever, it may not be as satisfactory. 


The idea of marrying theory and 
practice in one volume has much to 
recommend it. However, I feel that the 
major issues of operating system design 
would be more clearly illuminated by a 
smaller and simpler system. For an 
example of one more appropriate for 
this purpose, I recommend Douglas 
Comer’s book, Operating System 
Design: The Xinu Approach (Prentice- 
Hall, 1984). Xinu is a much smaller sys¬ 
tem, loosely based on Unix. It is suffi¬ 
ciently small and its design is of 
sufficient clarity for it to serve well as a 
pedagogical tool. It should be under¬ 
stood, however, that Comer, unlike 
Tanenbaum, makes no attempt to pro¬ 
vide a general introduction to operating 
system design. 

Andrew Kitchen 

Rochester Institute of Technology 


Relational Database: 
Selected Writings 

C.J. Date (Addison-Wesley 
Publishing Company, Reading, 

Mass., 1987,497 pp., $33.95) 

C.J. Date is one of the premier gurus 
of relational database systems, having 
been involved from the beginning in the 
development of both theory and 
products (IBM’s SQL/DS and DB2). 
This collection of his writings (from 
1974 on, including some previously 
unpublished papers) provides insight 
into some of the lesser known aspects of 
relational technology and a look at the 
development of his views on the subject 
(Date chose the papers to include). Each 
paper has a valuable section discussing 
its original publication, any rewriting 
(most have been edited to bring them up 
to date), and its current relevance. 

The book is divided into four sec¬ 
tions: relational overview, relational 
versus nonrelational systems, the SQL 
language, and database design. All 
argue for the use of relational database 
management systems, as well as discuss¬ 
ing theory, practice, and problems. 
There is more heat in some of the 
papers than you might expect, but rela¬ 
tional technology is an emotional topic 
among theorists and users and between 
advocates of different approaches. 

The overview section introduces 
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SQL/DS and gives informal and formal 
models of relational theory. It is 
interesting to contrast the formal defini¬ 
tions with Date’s discussion of actual 
implementations. He comments criti¬ 
cally on vendors’ failure, including 
IBM, to provide some of the more 
important aspects of the theory in their 
software. He uses the example of the 
debated topic of referential integrity. 
Date’s arguments are both convincing 
and heated, illustrating the unity of the 
theory and politics of software develop¬ 
ment. Many, if not most, database the¬ 
oreticians work for vendors of 
software—Date is no exception—and 
that shows in the discussions. 

Two of the most interesting and con¬ 
troversial topics are the interpretation 
of the relational model and the perfor¬ 
mance of relational systems versus non¬ 
relational ones. For the first, a good 
data model must have a “commonly 
accepted (and useful)” interpretation 
and must correspond to the real world. 
Date’s discussion of objects, rules, and 
operators differs from most in showing 
the relational model to be useful and a 
good model of the outside world. 
Understanding this has vital importance 
for database designers (and me). As 
elsewhere in the book, the technical lan¬ 
guage hints at conflicts with well known 
critics of the relational model. 

According to Date, many people 
think the performance of relational 
DBMSs limits their use to information 
center applications rather than produc¬ 
tion systems. The only valid reason for 
this is that nonrelational systems (spe¬ 
cifically IMS) have had more years to 
mature. In fact, a good relational sys¬ 
tem should offer more power than a 
nonrelational one because its data- 
access requests carry meaning and 
intent. Availability of metadata (data 
about the data), together with the abil¬ 
ity to see the complete data require¬ 
ment, should let a DBMS modify its 
access strategy to suit the situation. A 
hand-coded access request cannot be so 
optimized. 

According to Date, it seems quite 
possible that relational databases can be 
tuned for multiple production applica¬ 
tions and that they can adjust to chang¬ 
ing circumstances. The number of 
relational DBMSs (particularly in the 
DEC world) that can, and the lack of 
nonrelational DBMSs with such capa¬ 
bility, prove the point. He claims that 
DBMS users and designers generally 
recognize that development with rela¬ 
tional systems is easier, faster, and 
more accurate, yielding significantly 
faster returns on investment. 

Two flaws in the papers are Date’s 
references to Codasyl (Conference on 


Data Systems Languages) network 
logic, and an almost complete lack of 
reference to any system beyond 
SQL/DS and DB2. Like many rela¬ 
tional experts, he ignores any Codasyl 
DDLC (Data Description Language 
Committee—it hasn’t been DBTG, or 
Data Base Task Group, for years) 
development since 1971. There has been 
a lot. 

Structured Query Language has 
become an important topic recently 
with the growing support by Digital 
Equipment Corp., IBM, and others of 
their relational products, and with the 
development of an ANSI relationship 
standard using SQL. Date has been 
involved with SQL from its inception 
and devotes over 30 percent of the book 
to SQL alone. 

He asserts that (1) database languages 
are the only special-purpose program¬ 
ming languages with well-established 
principles for good design, and (2) there 
is little evidence that current database 
languages are designed using such prin¬ 
ciples. In particular, SQL fails in 

• its lack of orthogonality with 
respect to expressions, built-in func¬ 
tions, and other areas (the language 
structure is inconsistent); 

• its formal definition is not consis¬ 
tent with the language implementations 
(some important effects are undefined 
except by the implementer); 

• the absence of relational and pro¬ 
gramming interface functionality; and 

• the fallacy of some of its logic (for 
example, the result of an AVG, or aver¬ 
age, function when some of the aver¬ 
aged data is null). 

I should note that Date specifically 
targets DB2 and the ANSI X2H2 com¬ 
mittee’s then considerations of the DB2 
version of SQL as the standard. He 
does note SQL’s strong points and the 
fact that some of his criticisms may 
have been heard and responded to, but 
warns against the widespread adoption 
of SQL as it stands. 

Date also discusses SQL’s handling 
of nulls, outer joins, updates through 
views, and a proposed extension to eas¬ 
ily handle the parts-explosion problem. 

Papers in this book cover a broad 
range of relational topics. In spite of an 
overview section, you should not expect 
this to be a beginning text on relational 
concepts and practices. Instead, the 
book introduces and evaluates 
advanced and problematic aspects of 
the field, and discusses topics difficult 
to find in clear and simple form 
elsewhere. 

Date provides good examples and 
explanations. His book is an interesting 
and informative criticism by an expert 


in the field. I highly recommend it to 
anyone involved in database manage¬ 
ment, particularly those concerned with 
the future of the relational model. 

Robert M. Gross 

Day Data Systems 

High-Performance 
Computer Architecture 

Harold S. Stone (Addison-Wesley 

Publishing Company, Reading, 

Mass., 1987, 411 pp., $40.95) 

This text targets advanced under¬ 
graduate and first-year graduate stu¬ 
dents and assumes a prior course in 
computer organization as well as some 
programming experience, preferably 
including assembly language. A major 
goal of the text is to provide the student 
with the tools to evaluate past, present, 
and future computer architectures. To 
this end, the author expended consider¬ 
able effort describing the links between 
applications and architectures. 

The reader should not allow the title 
to mislead him or her into the belief 
that the book describes only exotic 
architectures. Rather, it discusses tech¬ 
niques relevant to most modern com¬ 
puters. 

The book opens with a justification 
for the emphasis on high performance 
techniques, including a discussion on 
measuring the cost/performance ratio 
for an architecture. It then highlights 
memory design, with special attention 
to cache memories and virtual-memory 
flechniques in general. A discussion of 
pipelining techniques in the design of 
control units includes an excellent sec¬ 
tion on the control of pipeline stages 
(which reflects back on earlier topics) 
and a short section on reduced instruc¬ 
tion set computing architecture. 

In Chapter 4, Stone develops a tax¬ 
onomy of numerical algorithms and dis¬ 
cusses the relationship between types of 
large numerical problems and the archi¬ 
tecture on which they are solved. This 
includes discussions of the Cosmic 
Cube and the Perfect Shuffle. The 
remainder of the book deals with vector 
computers, including attached vector 
processors; multiprocessor architecture, 
with an emphasis on loosely coupled 
systems (multicomputers); and parallel 
programming and the design of 
algorithms for multiprocessor 
architectures. 

The author has produced an excellent 
text, though I believe he may have 
exceeded his mark a bit. In a number of 
the chapters, he relies fairly heavily on 
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the reader having a firm grasp of 
numerical problems. In addition, he 
deals with architectural issues at a con¬ 
ceptual level with fewer concrete exam¬ 
ples than I prefer. The exercises at the 
end of the chapters are good. While 
they are at times somewhat long and 
involved, such is the nature of the topic. 

Overall, I feel that this is a good text 
for graduate-level computer science stu¬ 
dents and, augmented with slightly 
more detailed examples, it would serve 
well in most curricula. 

Peter H. Lutz 

Rochester Institute of Technology 


The Information Edge 

N. Dean Meyer and Mary E. Boone 

(McGraw-Hill Book Company, New 

York, 1987, 333 pp., $24.95) 

Although end-user computing has 
had major impact on the way people 
work and on the dissemination of infor¬ 
mation systems technology in engineer¬ 
ing, in science, and in the office, 
relatively few books deal with the sub¬ 
ject. Of course, trendy undergraduate 
textbooks for business students use 
“end-user computing” in their titles. 
However, most of these seem to be 
glossy picture books which repackage 
the standard introduction-to- 
information-systems course to appeal to 
the junior college audience. 

The Information Edge by Boone and 
Meyer looks at the end use of comput¬ 
ing to change the way people work and 
the leverage that can result. The book 
evaluates end-user computing in terms 
of its economic justification. Be warned 
that the book was written by advocates 
and that you have to be careful to sepa¬ 
rate the advocacy from the facts. 
Incidentally, the book does not refer to 
end-user computing by name in its 
index. 

Meyer and Boone are cheerleaders 
for the strategic use of information sys¬ 
tems, particularly for office automa¬ 
tion. Although their concept of 
strategic use is quite broad, they do 
have a consistent measuring stick for 
the benefits gained: value added. Meyer 
and Boone argue that value added mea¬ 
sures improved effectiveness and thus is 
a more appropriate yardstick than cost 
displacement, which is an efficiency 
gain. They present the largest number 
of examples of value added that I have 
seen in one place. Their examples range 
from selling and marketing to opera¬ 
tions, personnel, finance, new product 


introduction, and negotiation. They 
also discuss executive information sys¬ 
tems, and computer-aided meetings. 

For each of these areas, they present 
spectacular examples in which the 
benefits far exceed the investment. A 
typical example claims a 7500-percent 
five-year return on investment. Even if 
the benefit numbers are wildly inflated 
and the costs understated, the examples 
show significant changes resulting from 
the introduction of computing—in most 
cases, end-user computing. 

Typically for such compilations, the 
big successes are highlighted. Some of 
these are pure luck. For example, a 
manufacturer of chemical dispersants 
obtained the aforementioned 7500 per¬ 
cent return because an engineer found 
that tracking 128 variables on his PC 
(rather than 25 variables as had been 
done previously) isolated two major 
quality flaws which, when corrected, 
provided the gain. 

Meyer and Boone conclude their 
book with a discussion of the factors 
needed for successful implementation. 
These factors include recognizing 
potential end-user applications that 
have leverage, measuring the value- 
added benefits, and introducing value- 
added ideas into the organization. 

The book is written in a popular In 
Search of Excellence style that makes it 
a quick read, accessible to managers as 
well as technical people. The book is 
valuable because the large number of 
cases presented shows that end-user 
computing has—justifiably—become 
universal in organizations. In short, the 
end-user revolution is over. Now comes 
the more difficult task of managing the 
new world that has been created. Meyer 
and Boone should start you thinking 
about initiatives that you and your firm 
can undertake. 

Paul Gray 

Claremont Graduate School 


RS 232 Simplified — 
Everything You Need to 
Know 

Byron W. Putman (Prentice-Hall, 
Inc., Englewood Cliffs, N.J., 

1987, 190 pp., $26.67) 

The RS-232 serial interface standard 
was drafted in the 1960s by the Elec¬ 
tronics Industries Assoc. It was designed 
to create a hardware-independent envi¬ 
ronment between terminals, modems, 
and computers. In the 20 years since 


the inception of RS-232, computer 
hardware has evolved at an exponential 
rate, but the original standard has 
changed very little. 

According to the author, RS 232 Sim¬ 
plified illustrates RS-232 in the light of 
modern peripheral devices. It is not 
meant to be a theoretical treatise on for¬ 
mal serial interface design. After com¬ 
pleting this book, the reader should be 
able to correctly set up any RS-232 
device and design and construct custom 
interface cables. As such, it is intended 
for professional electronics technicians, 
ADP analysts, microcomputer hob¬ 
byists, and students taking formal one- 
semester courses on serial interfacing. 

The book opens with an introduction 
to digital electronics and the binary 
number system, addressing pertinent 
questions such as: How fast is the data 
stream transmitted? How will transmis¬ 
sion errors be detected? How will the 
receiver indicate to the transmitter that 
it is ready to receive data? The RS-232 
standard is then analyzed from the 
pragmatic point of view of DTEs and 
DCEs, the DB-25 pinout, and RS-232 
voltage/logic levels. Also examined are 
the differences between standard 
RS-232 terminals and the microcom¬ 
puter video monitors, terminal setup 
parameters, the concepts of program¬ 
ming terminals and terminal drivers, 
and terminal emulation with microcom¬ 
puters. 

In the final chapter, the author pulls 
it all together by showing how to design 
interface cables with the aid of 
manufacturer’s documentation and how 
to construct cables with a break-out 
box. The author defines an RS-232 
break-out box as test equipment typi¬ 
cally consisting of 24 switches and jum¬ 
per/patch points, 10 to 14 LED 
indicators, a package of assorted test 
jumpers, and two short lengths of inter¬ 
face cable terminating in standard 
DB-25 connectors. (The author has 
dedicated the book “To those coura¬ 
geous individuals who have taken a 
break-out box in hand and made an 
interface work.”) 

My only criticism of RS 232 Simpli¬ 
fied is that it makes no mention of the 
newer standards, notably RS-449, 
which was introduced in 1977 as a 
replacement for RS-232-C. Perhaps this 
is because RS-449, although offering a 
significant performance advantage over 
RS-232-C, has not yet displaced RS-232-C 
as the most popular standard. Higher 
costs and resistance to change are the 
hobgoblins—and the watchdogs—of 
progress. 

Chanden Sen 

North Carolina State University 
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NEW LITERATURE 


Microprocessors. The IEEE Press has 
announced two additions to the 
Selected Reprint Series edited by Amar 
Gupta and sponsored by the Computer 
Society. Advanced Microprocessors, II 
(PC02170, $28.15 members, $37.50 
nonmembers) focuses on advances in 
microprocessors, such as 32-bit chips 
and digital signal processors. The 
papers included cover devices released 
since 1983, when the first edition was 
published. 

Multi-Microprocessors (PC02162, 
$24.85 members, $33.15 nonmembers) 
covers microprocessor characteristics, 
support for multiprocessors, intercon¬ 
nection alternatives, bus protocols, per¬ 
formance modeling and simulation, and 
so forth. 

Contact IEEE Service Center, 445 
Hoes Lane, PO Box 1331, Piscataway, 
NJ 08855-1331. Shipping and handling 
charges are based on order totals. 

CAD/CAM for Mac. A new journal 
covers computer-aided design and man¬ 
ufacturing for the Apple Macintosh 
computer. The CAD /CAM Journal: 
For the Macintosh Professional 
includes evaluations of 2D and 3D 
drafting and design software, communi¬ 
cations and CAD, hardware evalua¬ 
tions, and new CAD/CAM/CAE 
products. Subscriptions to the four- 
color magazine are $20 per year for six 
issues. The CAD/CAM Journal, Circu¬ 
lation Dept., 16 Beaver St., New York, 
NY 10004; (212)425-4441. 

AI newsletter. The newsletter Applied 
Artificial Intelligence Reporter pub¬ 
lished by the University of Miami’s 
Intelligent Computer Systems Research 
Institute has changed its name to 
AlWeek and is now published twice 
monthly. It will continue to cover 
expert systems, AI industry meetings, 
and applications, as well as government 
funding, venture capital investment in 
AI firms, and so forth. Contact Jona¬ 
than D. Lynch, publisher, PO Box 
248235, Coral Gables, FL 33124; (305) 
284-5195. 

New from Frost & Sullivan. Value- 
Added Network Services in Europe (# 
E940, 317 pp., $2700) evaluates the 
growing VAN market in Europe. Net¬ 


work Management Systems in the U.S. 
(#A1802, 315 pp., $2200) explores the 
modest NMS market. The Videodisc 
Market in Europe (#E870, 245 pp., 
$2500) predicts average growth rates 
near 25 percent a year through 1991 in 
videodisc technology for the profes¬ 
sional, not consumer, market. 

The U.S. Market for Intelligent Com¬ 
munications Processors (#A1649, 265 
pp., $1950) predicts continued growth 
for the ICP market and technological 
developments in response to ISDN 
(Integrated Services Digital Network). 
Data and Voice Remote Testing Equip¬ 
ment (Ml805, 323 pp., $2000) evalu¬ 
ates the changing market for remote test 
equipment. 

Contact Frost & Sullivan, 106 Fulton 
St., New York, NY 10038-2786; (212) 
233-1080, or Frost & Sullivan Ltd., Sul¬ 
livan House, 4 Grosvenor Gardens, 
London SW1W ODH; (01) 730-3438. 


Supercomputer Vendor Directory (105 
pp., $95) from Electronic Trend Publi¬ 
cations profiles leading vendors in the 
supercomputer market. The directory 
divides into three categories: hardware, 
software, and third party. 

The hardware section profiles 45 ven¬ 
dors in the categories of supercom¬ 
puters, minisupercomputers, 
superminicomputers, fault-tolerant 
computers, application-oriented proces¬ 
sors, and workstations. The software 
and third-party vendors section profiles 
77 companies. 

The hardware vendor profiles include 
company name, address, telephone, 
date formed, number of people, prod¬ 
uct line summary, entry-level cost, date 
introduced, cumulative shipments to 
date, and market and product strategy. 

Contact Electronic Trend Publica¬ 
tions, 12930 Saratoga Ave., Suite Dl, 
Saratoga, CA 95070; (408) 996-7416. 

Online Database Search Services Direc¬ 
tory (ISBN 0-8103-2114-9, 1268 pp., 
$155), edited by Doris Morris Maxfield, 
describes the on-line search services 
offered by 1002 academic libraries, 158 
public libraries, 428 special libraries, 
and 157 information-on-demand firms. 
The second edition is geographically 
arranged. 


Details on each search service include 
on-line systems and databases routinely 
accessed, subject specialties, annual 
number of searches or hours spent on 
line, procedure for setting up a search, 
fee arrangement, additional communi¬ 
cations numbers, and names of search 
personnel. 

The directory is indexed by organiza¬ 
tion name, acronym, and subject key¬ 
words; databases searched; on-line 
systems accessed; and search personnel. 

Contact Gale Research Co., Book 
Tower, Detroit, MI 48226; (313) 
961-2242. 

On-line searching guide. The Oryx 
Press offers Online Searching for End 
Users: An Information Sourcebook 
(ISBN 0-89774-394-6, 128 pp., $37.50) 
as the first volume in the Oryx Source- 
book Series in Computer and Informa¬ 
tion Science. Sylvia Faibisoff is series 
editor; Fred Batt compiled the guide. 

The guide provides overviews and 
sources for on-line searching using 
intermediaries, searching by end users, 
and important aspects such as equip¬ 
ment, vendors, databases, software, 
interface systems, search strategies, and 
analysis by disciplines. The book also 
features a core library collection and 
author, title, and subject indexes. 

Contact The Oryx Press, Suite 103, 
2214 North Central at Encanto, Phoe¬ 
nix, AZ 85004-1483; (602) 244-6156 or 
(800) 457-ORYX. 


Simulation and AI. The Society of 
Manufacturing Engineers has collected 
25 technical papers on simulation and 
artificial intelligence in manufacturing. 
The papers focus on such topics as the 
steps involved in the simulation process, 
integrated factory communication 
through simulation, simulation tech¬ 
niques to improve production effi¬ 
ciency, the benefits of expert systems, 
coordinating robot motion, intelligent 
CAD/CAM databases, and so forth. 
Simulation and Artificial Intelligence 
Technical Papers (329 pp., $32 non¬ 
members, $28 SME members) is avail¬ 
able from the Society of Manufacturing 
Engineers, Publication Sales, One SME 
Drive, PO Box 930, Dearborn, MI 
48121; (313) 271-1500, ext. 418 or 419. 
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Purpose 

The Computer Society strives to advance the theory and practice 
of computer science and engineering. It promotes the exchange of 
technical information among its 90,000 members around the world, 
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members and nonmembers. 
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Moving Information 
From One Era Into Another 



At GTE’s Computer and In¬ 
telligent Systems Laboratory, 
we’ve intensified our focus and 
created new opportunities in Soft¬ 
ware and Information Engineering 
and Artificial Intelligence. Here, 
we apply new ideas to research 
and development projects for im¬ 
proved information and telecom¬ 
munication systems. 

By expanding our scope and 
responsibility, we can better sup¬ 
port GTE’s telecommunications 
businesses. And our activities 
create challenges for individuals at 
the MS/PhD level in Computer 
Science. Join us as we continue to 
make history in telecommunica¬ 
tions technology. 


Areas of expertise: 

• SOFTWARE REUSABILITY 

• PROGRAMMING 
ENVIRONMENTS 

• SOFTWARE-DEFINED 
SERVICES FOR 
INTELLIGENT NETWORKS 

• INFORMATION RETRIEVAL 

• INTELLIGENT DATABASE 
MANAGEMENT SYSTEMS 

• APPLIED EXPERT 
SYSTEMS 

• EXECUTABLE 
SPECIFICATIONS 

• RAPID PROTOTYPING 

• ENTERPRISE ANALYSIS 
AND BUSINESS MODELING 


• DISTRIBUTED ARTIFICIAL 
INTELLIGENCE 

• LOGIC PROGRAMMING 

• MACHINE LEARNING 

• OPERATING SYSTEMS 

• CONNECTIONIST 
MODELING 

GTE Laboratories offers attrac¬ 
tive facilities located in a quiet, 
wooded setting just outside of 
Boston as well as a highly com¬ 
petitive salary and benefits pack¬ 
age. We invite you to send a 
resume to Vanessa Stem, GTE 
Laboratories, Inc., Box IEEE2, 
40 Sylvan Road, Waltham, MA 
02254. An equal opportunity 
employer, M/F/H/V. 
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